draft-ietf-perc-double-03.txt		draft-ietf-perc-double-04.txt
	Network Working Group C. Jennings		Network Working Group C. Jennings
	Internet-Draft P. Jones		Internet-Draft P. Jones
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: September 14, 2017 A. Roach		Expires: October 30, 2017 A. Roach
	Mozilla		Mozilla
	March 13, 2017		April 28, 2017
	SRTP Double Encryption Procedures		SRTP Double Encryption Procedures
	draft-ietf-perc-double-03		draft-ietf-perc-double-04
	Abstract		Abstract
	In some conferencing scenarios, it is desirable for an intermediary		In some conferencing scenarios, it is desirable for an intermediary
	to be able to manipulate some RTP parameters, while still providing		to be able to manipulate some RTP parameters, while still providing
	strong end-to-end security guarantees. This document defines SRTP		strong end-to-end security guarantees. This document defines SRTP
	procedures that use two separate but related cryptographic contexts		procedures that use two separate but related cryptographic contexts
	to provide "hop-by-hop" and "end-to-end" security guarantees. Both		to provide "hop-by-hop" and "end-to-end" security guarantees. Both
	the end-to-end and hop-by-hop cryptographic transforms can utilize an		the end-to-end and hop-by-hop cryptographic transforms can utilize an
	authenticated encryption with associated data scheme or take		authenticated encryption with associated data scheme or take
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 September 14, 2017.		This Internet-Draft will expire on October 30, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Cryptographic Contexts . . . . . . . . . . . . . . . . . . . 3		3. Cryptographic Contexts . . . . . . . . . . . . . . . . . . . 3
	4. Original Header Block . . . . . . . . . . . . . . . . . . . . 4		4. Original Header Block . . . . . . . . . . . . . . . . . . . . 4
	5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 5		5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 5		5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 6
	5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6		5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6
	5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 7		5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 8
	6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 8		6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Recommended Inner and Outer Cryptographic Transforms . . . . 8		7. Recommended Inner and Outer Cryptographic Transforms . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 10		9.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 11
	9.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 10		9.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Cloud conferencing systems that are based on switched conferencing		Cloud conferencing systems that are based on switched conferencing
	have a central Media Distributor device that receives media from		have a central Media Distributor device that receives media from
	endpoints and distributes it to other endpoints, but does not need to		endpoints and distributes it to other endpoints, but does not need to
	interpret or change the media content. For these systems, it is		interpret or change the media content. For these systems, it is
	desirable to have one cryptographic context from the sending endpoint		desirable to have one cryptographic context from the sending endpoint
	to the receiving endpoint that can encrypt and authenticate the media		to the receiving endpoint that can encrypt and authenticate the media
	end-to-end while still allowing certain RTP header information to be		end-to-end while still allowing certain RTP header information to be
	changed by the Media Distributor. At the same time, a separate		changed by the Media Distributor. At the same time, a separate
	cryptographic context provides integrity and optional confidentiality		cryptographic context provides integrity and optional confidentiality
	for the media flowing between the Media Distributor and the		for the media flowing between the Media Distributor and the
	endpoints. See the framework document that describes this concept in		endpoints. See the framework document that describes this concept in
	more detail in more detail in		more detail in more detail in
	[I-D.ietf-perc-private-media-framework].		[I-D.ietf-perc-private-media-framework].
	This specification RECOMMENDS the SRTP AES-GCM transform [RFC7714] to		This specification defines an SRTP transform that uses the AES-GCM
	encrypt an RTP packet for the end-to-end cryptographic context. The		transform [RFC7714] to encrypt an RTP packet for the end-to-end
	output of this is treated as an RTP packet and again encrypted with		cryptographic context. The output of this is treated as an RTP
	an SRTP transform used in the hop-by-hop cryptographic context		packet and again encrypted with an SRTP transform used in the hop-by-
	between the endpoint and the Media Distributor. The Media		hop cryptographic context between the endpoint and the Media
	Distributor decrypts and checks integrity of the hop-by-hop security.		Distributor. The Media Distributor decrypts and checks integrity of
	The Media Distributor MAY change some of the RTP header information		the hop-by-hop security. The Media Distributor MAY change some of
	that would impact the end-to-end integrity. The original value of		the RTP header information that would impact the end-to-end
	any RTP header field that is changed is included in a new RTP header		integrity. The original value of any RTP header field that is
	extension called the Original Header Block. The new RTP packet is		changed is included in a new RTP header extension called the Original
	encrypted with the hop-by-hop cryptographic transform before it is		Header Block. The new RTP packet is encrypted with the hop-by-hop
	sent. The receiving endpoint decrypts and checks integrity using the		cryptographic transform before it is sent. The receiving endpoint
	hop-by-hop cryptographic transform and then replaces any parameters		decrypts and checks integrity using the hop-by-hop cryptographic
	the Media Distributor changed using the information in the Original		transform and then replaces any parameters the Media Distributor
	Header Block before decrypting and checking the end-to-end integrity.		changed using the information in the Original Header Block before
			decrypting and checking the end-to-end integrity.
			One can think of the double as a normal SRTP transform as encrypting
			the RTP in a way where things that only know half of the key, can
			decrypt and modify part of the RTP packet but not other parts of if
			including the media payload.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Terms used throughout this document include:		Terms used throughout this document include:
	o Media Distributor: media distribution device that routes media		o Media Distributor: media distribution device that routes media
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 16 ¶
	AES-GCM. Other combinations of SRTP ciphers that support the		AES-GCM. Other combinations of SRTP ciphers that support the
	procedures in this document can be added to the IANA registry.		procedures in this document can be added to the IANA registry.
	The keys and salt for these contexts are generated with the following		The keys and salt for these contexts are generated with the following
	steps:		steps:
	o Generate key and salt values of the length required for the		o Generate key and salt values of the length required for the
	combined inner (end-to-end) and outer (hop-by-hop) transforms.		combined inner (end-to-end) and outer (hop-by-hop) transforms.
	o Assign the key and salt values generated for the inner (end-to-		o Assign the key and salt values generated for the inner (end-to-
	end) transform.		end) transform to the first half of the key and salt for the
			double transform.
	o Assign the key and salt values for the outer (hop-by-hop)		o Assign the key and salt values for the outer (hop-by-hop)
			transform to the second half of the key and salt for the double
	transform.		transform.
	Obviously, if the Media Distributor is to be able to modify header		Obviously, if the Media Distributor is to be able to modify header
	fields but not decrypt the payload, then it must have cryptographic		fields but not decrypt the payload, then it must have cryptographic
	context for the outer transform, but not the inner transform. This		context for the outer transform, but not the inner transform. This
	document does not define how the Media Distributor should be		document does not define how the Media Distributor should be
	provisioned with this information. One possible way to provide		provisioned with this information. One possible way to provide
	keying material for the outer ("hop-by-hop") transform is to use		keying material for the outer ("hop-by-hop") transform is to use
	[I-D.ietf-perc-dtls-tunnel].		[I-D.ietf-perc-dtls-tunnel].
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 22 ¶
	o Apply the inner cryptographic transform to the RTP packet. If		o Apply the inner cryptographic transform to the RTP packet. If
	encrypting RTP header extensions end-to-end, then [RFC6904] MUST		encrypting RTP header extensions end-to-end, then [RFC6904] MUST
	be used when encrypting the RTP packet using the inner		be used when encrypting the RTP packet using the inner
	cryptographic context.		cryptographic context.
	o If the endpoint wishes to insert header extensions that can be		o If the endpoint wishes to insert header extensions that can be
	modified by an Media Distributor, it MUST insert an OHB header		modified by an Media Distributor, it MUST insert an OHB header
	extension at the end of any header extensions protected end-to-end		extension at the end of any header extensions protected end-to-end
	(if any), then add any Media Distributor-modifiable header		(if any), then add any Media Distributor-modifiable header
	extensions. The OHB MUST replicate the information found in the		extensions. In other cases, the endpoint SHOULD still insert an
	RTP header following the application of the inner cryptographic		OHB header extension. The OHB MUST replicate the information
	transform. If not already set, the endpoint MUST set the X bit in		found in the RTP header following the application of the inner
	the RTP header to 1 when introducing the OHB extension.		cryptographic transform. If not already set, the endpoint MUST
			set the X bit in the RTP header to 1 when introducing the OHB
			extension.
	o Apply the outer cryptographic transform to the RTP packet. If		o Apply the outer cryptographic transform to the RTP packet. If
	encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST		encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST
	be used when encrypting the RTP packet using the outer		be used when encrypting the RTP packet using the outer
	cryptographic context.		cryptographic context.
	When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes		When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes
	after the SRTP packet exactly like using EKT with any other SRTP		after the SRTP packet exactly like using EKT with any other SRTP
	transform.		transform.
	skipping to change at page 8, line 35 ¶		skipping to change at page 9, line 5 ¶
	correct behavior. The application MUST use only the information		correct behavior. The application MUST use only the information
	found in the synthetic SRTP packet and MUST NOT use the other data		found in the synthetic SRTP packet and MUST NOT use the other data
	that was in the outer SRTP packet with the following exceptions:		that was in the outer SRTP packet with the following exceptions:
	o The PT from the outer SRTP packet is used for normal matching to		o The PT from the outer SRTP packet is used for normal matching to
	SDP and codec selection.		SDP and codec selection.
	o The sequence number from the outer SRTP packet is used for normal		o The sequence number from the outer SRTP packet is used for normal
	RTP ordering.		RTP ordering.
			The PT and sequence number from the inner SRTP packet can be used for
			collection of various statistics.
	If any of the following RTP headers extensions are found in the outer		If any of the following RTP headers extensions are found in the outer
	SRTP packet, they MAY be used:		SRTP packet, they MAY be used:
	o Mixer-to-client audio level indicators (See [RFC6465])		o Mixer-to-client audio level indicators (See [RFC6465])
	6. RTCP Operations		6. RTCP Operations
	Unlike RTP, which is encrypted both hop-by-hop and end-to-end using		Unlike RTP, which is encrypted both hop-by-hop and end-to-end using
	two separate cryptographic contexts, RTCP is encrypted using only the		two separate cryptographic contexts, RTCP is encrypted using only the
	outer (HBH) cryptographic context. The procedures for RTCP		outer (HBH) cryptographic context. The procedures for RTCP
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 26 ¶
	The Media Distributor has the HBH key so it can check the		The Media Distributor has the HBH key so it can check the
	authentication of the received packet across the initial envelope and		authentication of the received packet across the initial envelope and
	payload data but it can't decrypt the payload as it does not have the		payload data but it can't decrypt the payload as it does not have the
	E2E key. It can add extra envelope information. It then		E2E key. It can add extra envelope information. It then
	authenticates the initial plus extra envelope information plus		authenticates the initial plus extra envelope information plus
	payload with a HBH key. This HBH for the outgoing packet is		payload with a HBH key. This HBH for the outgoing packet is
	typically different than the HBH key for the incoming packet.		typically different than the HBH key for the incoming packet.
	The receiver can check the authentication of the initial and extra		The receiver can check the authentication of the initial and extra
	envelope information. This, along with the OBH, is used to construct		envelope information. This, along with the OHB, is used to construct
	a synthetic packet that is should be identical to one the sender		a synthetic packet that is should be identical to one the sender
	created and the receiver can check that it is identical and then		created and the receiver can check that it is identical and then
	decrypt the original payload.		decrypt the original payload.
	The end result is that if the authentications succeed, the receiver		The end result is that if the authentications succeed, the receiver
	knows exactly what the original sender sent, as well as exactly which		knows exactly what the original sender sent, as well as exactly which
	modifications were made by the Media Distributor.		modifications were made by the Media Distributor.
	It is obviously critical that the intermediary has only the outer		It is obviously critical that the intermediary has only the outer
	transform parameters and not the inner transform parameters. We rely		transform parameters and not the inner transform parameters. We rely
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 42 ¶
	Many thanks to Richard Barnes for sending significant text for this		Many thanks to Richard Barnes for sending significant text for this
	specification. Thank you for reviews and improvements from David		specification. Thank you for reviews and improvements from David
	Benham, Paul Jones, Suhas Nandakumar, Nils Ohlmeier, and Magnus		Benham, Paul Jones, Suhas Nandakumar, Nils Ohlmeier, and Magnus
	Westerlund.		Westerlund.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<http://www.rfc-editor.org/info/rfc3711>.		<http://www.rfc-editor.org/info/rfc3711>.
	[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP		[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
	Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July		Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
	2008, <http://www.rfc-editor.org/info/rfc5285>.		2008, <http://www.rfc-editor.org/info/rfc5285>.
	[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, DOI		Real-time Transport Protocol (SRTP)", RFC 5764,
	10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010,
	<http://www.rfc-editor.org/info/rfc5764>.		<http://www.rfc-editor.org/info/rfc5764>.
	[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure		[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
	Real-time Transport Protocol (SRTP)", RFC 6904, DOI		Real-time Transport Protocol (SRTP)", RFC 6904,
	10.17487/RFC6904, April 2013,		DOI 10.17487/RFC6904, April 2013,
	<http://www.rfc-editor.org/info/rfc6904>.		<http://www.rfc-editor.org/info/rfc6904>.
	[RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption		[RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
	in the Secure Real-time Transport Protocol (SRTP)", RFC		in the Secure Real-time Transport Protocol (SRTP)",
	7714, DOI 10.17487/RFC7714, December 2015,		RFC 7714, DOI 10.17487/RFC7714, December 2015,
	<http://www.rfc-editor.org/info/rfc7714>.		<http://www.rfc-editor.org/info/rfc7714>.
	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", March 2017.		Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00
			(work in progress), March 2017.
	[I-D.ietf-perc-private-media-framework]		[I-D.ietf-perc-private-media-framework]
	Jones, P., Benham, D., and C. Groves, "A Solution		Jones, P., Benham, D., and C. Groves, "A Solution
	Framework for Private Media in Privacy Enhanced RTP		Framework for Private Media in Privacy Enhanced RTP
	Conferencing", draft-ietf-perc-private-media-framework-02		Conferencing", draft-ietf-perc-private-media-framework-03
	(work in progress), October 2016.		(work in progress), March 2017.
	[I-D.ietf-perc-srtp-ekt-diet]		[I-D.ietf-perc-srtp-ekt-diet]
	Jennings, C., Mattsson, J., McGrew, D., and D. Wing,		Jennings, C., Mattsson, J., McGrew, D., and D. Wing,
	"Encrypted Key Transport for Secure RTP", draft-ietf-perc-		"Encrypted Key Transport for Secure RTP", draft-ietf-perc-
	srtp-ekt-diet-02 (work in progress), October 2016.		srtp-ekt-diet-03 (work in progress), March 2017.
	[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-		[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
	time Transport Protocol (RTP) Header Extension for Mixer-		time Transport Protocol (RTP) Header Extension for Mixer-
	to-Client Audio Level Indication", RFC 6465, DOI 10.17487/		to-Client Audio Level Indication", RFC 6465,
	RFC6465, December 2011,		DOI 10.17487/RFC6465, December 2011,
	<http://www.rfc-editor.org/info/rfc6465>.		<http://www.rfc-editor.org/info/rfc6465>.
	Authors' Addresses		Authors' Addresses
	Cullen Jennings		Cullen Jennings
	Cisco Systems		Cisco Systems
	Email: fluffy@iii.ca		Email: fluffy@iii.ca
	Paul E. Jones		Paul E. Jones
End of changes. 22 change blocks.
	49 lines changed or deleted		63 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/