draft-ietf-perc-double-02.txt		draft-ietf-perc-double-03.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: May 4, 2017 A. Roach		Expires: September 14, 2017 A. Roach
	Mozilla		Mozilla
	October 31, 2016		March 13, 2017
	SRTP Double Encryption Procedures		SRTP Double Encryption Procedures
	draft-ietf-perc-double-02		draft-ietf-perc-double-03
	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 May 4, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	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 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 5		5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 5
	5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6		5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6
	5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 7		5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 7
	6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 8		6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Recommended Inner and Outer Cryptographic Transforms . . . . 8		7. Recommended Inner and Outer Cryptographic Transforms . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 10		9.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 10
	9.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 10		9.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 10
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	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.jones-perc-private-media-framework].		[I-D.ietf-perc-private-media-framework].
	This specification RECOMMENDS the SRTP AES-GCM transform [RFC7714] to		This specification RECOMMENDS the SRTP AES-GCM transform [RFC7714] to
	encrypt an RTP packet for the end-to-end cryptographic context. The		encrypt an RTP packet for the end-to-end cryptographic context. The
	output of this is treated as an RTP packet and again encrypted with		output of this is treated as an RTP packet and again encrypted with
	an SRTP transform used in the hop-by-hop cryptographic context		an SRTP transform used in the hop-by-hop cryptographic context
	between the endpoint and the Media Distributor. The Media		between the endpoint and the Media Distributor. The Media
	Distributor decrypts and checks integrity of the hop-by-hop security.		Distributor decrypts and checks integrity of the hop-by-hop security.
	The Media Distributor MAY change some of the RTP header information		The Media Distributor MAY change some of the RTP header information
	that would impact the end-to-end integrity. The original value of		that would impact the end-to-end integrity. The original value of
	any RTP header field that is changed is included in a new RTP header		any RTP header field that is changed is included in a new RTP header
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	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.		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.jones-perc-dtls-tunnel].		[I-D.ietf-perc-dtls-tunnel].
	4. Original Header Block		4. Original Header Block
	Any SRTP packet processed following these procedures MAY contain an		Any SRTP packet processed following these procedures MAY contain an
	Original Header Block (OHB) RTP header extension.		Original Header Block (OHB) RTP header extension.
	The OHB contains the original values of any modified header fields		The OHB contains the original values of any modified header fields
	and MUST be placed after any already-existing RTP header extensions.		and MUST be placed after any already-existing RTP header extensions.
	Placement of the OHB after any original header extensions is		Placement of the OHB after any original header extensions is
	important so that the receiving endpoint can properly authenticate		important so that the receiving endpoint can properly authenticate
	skipping to change at page 4, line 48 ¶		skipping to change at page 4, line 48 ¶
	The Media Distributor is only permitted to modify the extension (X)		The Media Distributor is only permitted to modify the extension (X)
	bit, payload type (PT) field, and the RTP sequence number field.		bit, payload type (PT) field, and the RTP sequence number field.
	The OHB extension is either one octet in length, two octets in		The OHB extension is either one octet in length, two octets in
	length, or three octets in length. The length of the OHB indicates		length, or three octets in length. The length of the OHB indicates
	what data is contained in the extension.		what data is contained in the extension.
	If the OHB is one octet in length, it contains the original PT field		If the OHB is one octet in length, it contains the original PT field
	value. In this case, the OHB has this form:		value. In this case, the OHB has this form:
	0		0 1
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---------------+		+-+-+-+-+-+-+-+-+---------------+
	|R| PT |		| ID | len=0 |R| PT |
	+---------------+		+-+-+-+-+-+-+-+-+---------------+
	Note that "R" indicates a reserved bit that MUST be set to zero when		Note that "R" indicates a reserved bit that MUST be set to zero when
	sending a packet and ignored upon receipt.		sending a packet and ignored upon receipt. ID is the RTP Header
			Extension identifier negotiated in the SDP.
	If the OHB is two octets in length, it contains the original RTP		If the OHB is two octets in length, it contains the original RTP
	packet sequence number. In this case, the OHB has this form:		packet sequence number. In this case, the OHB has this form:
	0 1		0 1 2
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
	+-------------------------------+		+-+-+-+-+-+-+-+-+-------------------------------+
	| Sequence Number |		| ID | len=1 | Sequence Number |
	+-------------------------------+		+-+-+-+-+-+-+-+-+-------------------------------+
	If the OHB is three octets in length, it contains the original PT		If the OHB is three octets in length, it contains the original PT
	field value and RTP packet sequence number. In this case, the OHB		field value and RTP packet sequence number. In this case, the OHB
	has this form:		has this form:
	0 1 2		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 6 4 5 6 7 8 9 1
	+---------------+-------------------------------+		+-+-+-+-+-+-+-+-+---------------+-------------------------------+
	|R| PT | Sequence Number |		| ID | len=2 |R| PT | Sequence Number |
	+---------------+-------------------------------+		+-+-+-+-+-+-+-+-+---------------+-------------------------------+
	If a Media Distributor modifies an original RTP header value, the		If a Media Distributor modifies an original RTP header value, the
	Media Distributor MUST include the OHB extension to reflect the		Media Distributor MUST include the OHB extension to reflect the
	changed value, setting the X bit in the RTP header to 1 if no header		changed value, setting the X bit in the RTP header to 1 if no header
	extensions were originally present. If another Media Distributor		extensions were originally present. If another Media Distributor
	along the media path makes additional changes to the RTP header and		along the media path makes additional changes to the RTP header and
	any original value is already present in the OHB, the Media		any original value is already present in the OHB, the Media
	Distributor must extend the OHB by adding the changed value to the		Distributor must extend the OHB by adding the changed value to the
	OHB. To properly preserve original RTP header values, a Media		OHB. To properly preserve original RTP header values, a Media
	Distributor MUST NOT change a value already present in the OHB		Distributor MUST NOT change a value already present in the OHB
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 21 ¶
	extensions. The OHB MUST replicate the information found in the		extensions. The OHB MUST replicate the information found in the
	RTP header following the application of the inner cryptographic		RTP header following the application of the inner cryptographic
	transform. If not already set, the endpoint MUST set the X bit in		transform. If not already set, the endpoint MUST set the X bit in
	the RTP header to 1 when introducing the OHB extension.		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
			after the SRTP packet exactly like using EKT with any other SRTP
			transform.
	5.2. Relaying a Packet		5.2. Relaying a Packet
	The Media Distributor does not have a notion of outer or inner		The Media Distributor does not have a notion of outer or inner
	cryptographic contexts. Rather, the Media Distributor has a single		cryptographic contexts. Rather, the Media Distributor has a single
	cryptographic context. The cryptographic transform and key used to		cryptographic context. The cryptographic transform and key used to
	decrypt a packet and any encrypted RTP header extensions would be the		decrypt a packet and any encrypted RTP header extensions would be the
	same as those used in the endpoint's outer cryptographic context.		same as those used in the endpoint's outer cryptographic context.
	In order to modify a packet, the Media Distributor decrypts the		In order to modify a packet, the Media Distributor decrypts the
	packet, modifies the packet, updates the OHB with any modifications		packet, modifies the packet, updates the OHB with any modifications
	skipping to change at page 11, line 37 ¶		skipping to change at page 11, line 44 ¶
	auth_key_length: N/A		auth_key_length: N/A
	auth_tag_length: N/A		auth_tag_length: N/A
	maximum lifetime: at most 2^31 SRTCP packets and		maximum lifetime: at most 2^31 SRTCP packets and
	at most 2^48 SRTP packets		at most 2^48 SRTP packets
	The first half of the key and salt is used for the inner (E2E)		The first half of the key and salt is used for the inner (E2E)
	transform and the second half is used for the outer (HBH) transform.		transform and the second half is used for the outer (HBH) transform.
	10. Acknowledgments		10. Acknowledgments
	Many thanks to review from Suhas Nandakumar, David Benham, Magnus		Many thanks to Richard Barnes for sending significant text for this
	Westerlund and significant text from Richard Barnes.		specification. Thank you for reviews and improvements from David
			Benham, Paul Jones, Suhas Nandakumar, Nils Ohlmeier, and Magnus
			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,		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	DOI 10.17487/RFC2119, March 1997,		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,		Real-time Transport Protocol (SRTP)", RFC 5764, DOI
	DOI 10.17487/RFC5764, May 2010,		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,		Real-time Transport Protocol (SRTP)", RFC 6904, DOI
	DOI 10.17487/RFC6904, April 2013,		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)",		in the Secure Real-time Transport Protocol (SRTP)", RFC
	RFC 7714, DOI 10.17487/RFC7714, December 2015,		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.jones-perc-dtls-tunnel]		[I-D.ietf-perc-dtls-tunnel]
	Jones, P., "A DTLS Tunnel between Media Distributor and		Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
	Key Distributor to Facilitate Key Exchange", draft-jones-		between a Media Distributor and Key Distributor to
	perc-dtls-tunnel-03 (work in progress), July 2016.		Facilitate Key Exchange", March 2017.
	[I-D.jones-perc-private-media-framework]		[I-D.ietf-perc-private-media-framework]
	Jones, P. and D. Benham, "A Solution Framework for Private		Jones, P., Benham, D., and C. Groves, "A Solution
	Media in Privacy Enhanced RTP Conferencing", draft-jones-		Framework for Private Media in Privacy Enhanced RTP
	perc-private-media-framework-02 (work in progress), March		Conferencing", draft-ietf-perc-private-media-framework-02
	2016.		(work in progress), October 2016.
			[I-D.ietf-perc-srtp-ekt-diet]
			Jennings, C., Mattsson, J., McGrew, D., and D. Wing,
			"Encrypted Key Transport for Secure RTP", draft-ietf-perc-
			srtp-ekt-diet-02 (work in progress), October 2016.
	[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,		to-Client Audio Level Indication", RFC 6465, DOI 10.17487/
	DOI 10.17487/RFC6465, December 2011,		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
	Cisco Systems		Cisco Systems
	Email: paulej@packetizer.com		Email: paulej@packetizer.com
	Adam Roach		Adam Roach
	Mozilla		Mozilla
	Email: adam@nostrum.com		Email: adam@nostrum.com
End of changes. 23 change blocks.
	47 lines changed or deleted		60 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/