draft-ietf-perc-srtp-ekt-diet-01.txt		draft-ietf-perc-srtp-ekt-diet-02.txt
	PERC Working Group J. Mattsson, Ed.		PERC Working Group C. Jennings
	Internet-Draft Ericsson		Internet-Draft Cisco
	Intended status: Standards Track D. McGrew		Intended status: Standards Track J. Mattsson, Ed.
	Expires: January 9, 2017 D. Wing		Expires: May 4, 2017 Ericsson
			D. McGrew
			D. Wing
	F. Andreasen		F. Andreasen
	C. Jennings
	Cisco		Cisco
	July 8, 2016		October 31, 2016
	Encrypted Key Transport for Secure RTP		Encrypted Key Transport for Secure RTP
	draft-ietf-perc-srtp-ekt-diet-01		draft-ietf-perc-srtp-ekt-diet-02
	Abstract		Abstract
	Encrypted Key Transport (EKT) is an extension to Secure Real-time		Encrypted Key Transport (EKT) is an extension to Secure Real-time
	Transport Protocol (SRTP) that provides for the secure transport of		Transport Protocol (SRTP) that provides for the secure transport of
	SRTP master keys, Rollover Counters, and other information within		SRTP master keys, rollover counters, and other information within
	SRTP. This facility enables SRTP to work for decentralized		SRTP. This facility enables SRTP for decentralized conferences by
	conferences with minimal control by allowing a common key to be used		distributing a common key to all of the conference endpoints.
	across multiple endpoints.
	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 9, 2017.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 18 ¶		skipping to change at page 2, line 18 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions Used In This Document . . . . . . . . . . . . 3		1.1. Conventions Used In This Document . . . . . . . . . . . . 3
	2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 3		2. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 3
	2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4		2.1. EKT Field Formats . . . . . . . . . . . . . . . . . . . . 4
	2.2. Packet Processing and State Machine . . . . . . . . . . . 6		2.2. Packet Processing and State Machine . . . . . . . . . . . 6
	2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 7		2.2.1. Outbound Processing . . . . . . . . . . . . . . . . . 7
	2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 7		2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 8
	2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.1. The Default Cipher . . . . . . . . . . . . . . . . . 9		2.3.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 10
	2.3.2. Other EKT Ciphers . . . . . . . . . . . . . . . . . . 10		2.3.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 10
	2.4. Synchronizing		2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 10
	Operation . . . . . . . . . . . . . . . . . . . . . . . . 10		2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 10
	2.6. Timing and Reliability Consideration . . . . . . . . . . 11		2.6. Timing and Reliability Consideration . . . . . . . . . . 11
	3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 11		3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 12
	3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 12		3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 12
	3.2. EKT Extensions to DTLS-SRTP . . . . . . . . . . . . . . . 12		3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 12
	3.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 14		3.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 15
	4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . . . 14		3.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 15
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 17
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		5.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Normative References . . . . . . . . . . . . . . . . . . 16		5.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . 17		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
			7.1. Normative References . . . . . . . . . . . . . . . . . . 19
			7.2. Informative References . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	RTP is designed to allow decentralized groups with minimal control to		Real-time Transport Protocol (RTP) is designed to allow decentralized
	establish sessions, such as for multimedia conferences.		groups with minimal control to establish sessions, such as for
	Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many		multimedia conferences. Unfortunately, Secure RTP ( SRTP [RFC3711])
	minimal-control scenarios, because it requires that SSRC values and		cannot be used in many minimal-control scenarios, because it requires
	other data be coordinated among all of the participants in a session.		that synchronization source (SSRC) values and other data be
	For example, if a participant joins a session that is already in		coordinated among all of the participants in a session. For example,
	progress, that participant needs to be told the SRTP keys (and SSRC,		if a participant joins a session that is already in progress, that
	ROC and other details) of the other SRTP sources.		participant needs to be told the SRTP keys along with the SSRC, roll
			over counter (ROC) and other details of the other SRTP sources.
	The inability of SRTP to work in the absence of central control was		The inability of SRTP to work in the absence of central control was
	well understood during the design of the protocol; the omission was		well understood during the design of the protocol; the omission was
	considered less important than optimizations such as bandwidth		considered less important than optimizations such as bandwidth
	conservation. Additionally, in many situations SRTP is used in		conservation. Additionally, in many situations SRTP is used in
	conjunction with a signaling system that can provide most of the		conjunction with a signaling system that can provide the central
	central control needed by SRTP. However, there are several cases in		control needed by SRTP. However, there are several cases in which
	which conventional signaling systems cannot easily provide all of the		conventional signaling systems cannot easily provide all of the
	coordination required. It is also desirable to eliminate the layer		coordination required. It is also desirable to eliminate the layer
	violations that occur when signaling systems coordinate certain SRTP		violations that occur when signaling systems coordinate certain SRTP
	parameters, such as SSRC values and ROCs.		parameters, such as SSRC values and ROCs.
	This document defines Encrypted Key Transport (EKT) for SRTP and		This document defines Encrypted Key Transport (EKT) for SRTP and
	reduces the amount of external signaling control that is needed in a		reduces the amount of external signaling control that is needed in a
	SRTP session that is shared with multiple receivers. EKT securely		SRTP session with multiple receivers. EKT securely distributes the
	distributes the SRTP master key and other information for each SRTP		SRTP master key and other information for each SRTP source. With
	source. With this method, SRTP entities are free to choose SSRC		this method, SRTP entities are free to choose SSRC values as they see
	values as they see fit, and to start up new SRTP sources (SSRC) with		fit, and to start up new SRTP sources with new SRTP master keys (see
	new SRTP master keys (see Section 2.2) within a session without		Section 2.2) within a session without coordinating with other
	coordinating with other entities via external signaling or other		entities via external signaling or other external means.
	external means.
	EKT provides a way for an SRTP session participant, either a sender		EKT provides a way for an SRTP session participant, either a sender
	or receiver, to securely transport its SRTP master key and current		or receiver, to securely transport its SRTP master key and current
	SRTP rollover counter to the other participants in the session. This		SRTP rollover counter to the other participants in the session. This
	data furnishes the information needed by the receiver to instantiate		data furnishes the information needed by the receiver to instantiate
	an SRTP/SRTCP receiver context.		an SRTP/SRTCP receiver context.
	EKT does not control the manner in which the SSRC is generated; it is		EKT does not control the manner in which the SSRC is generated; it is
	only concerned with their secure transport.		only concerned with their secure transport.
	EKT is not intended to replace external key establishment mechanisms,		EKT is not intended to replace external key establishment mechanisms.
	Instead, it is used in conjunction with those methods, and it		Instead, it is used in conjunction with those methods, and it
	relieves them of the burden of tightly coordinating every SRTP source		relieves those methods of the burden to deliver the context for each
	(SSRC) among every SRTP participant.		SRTP source to every SRTP participant.
	1.1. Conventions Used In This Document		1.1. Conventions Used In This Document
	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].
	2. Encrypted Key Transport		2. Encrypted Key Transport
	EKT defines a new method of providing SRTP master keys to an		EKT defines a new method of providing SRTP master keys to an
	endpoint. In order to convey the ciphertext of the SRTP master key,		endpoint. In order to convey the ciphertext corresponding to the
	and other additional information, an additional EKT field is added to		SRTP master key, and other additional information, an additional EKT
	SRTP packets. When added to SRTP, the EKT field appears at the end		field is added to SRTP packets. When added to SRTP, the EKT field
	of the SRTP packet, after the authentication tag (if that tag is		appears at the end of the SRTP packet, after the authentication tag
	present), or after the ciphertext of the encrypted portion of the		(if that tag is present), or after the ciphertext of the encrypted
	packet otherwise.		portion of the packet otherwise.
	EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key		EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
	Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP		Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
	features duplicate some of the functions of EKT.		features duplicate some of the functions of EKT.
	2.1. EKT Field Formats		2.1. EKT Field Formats
	The EKT Field uses the format defined below for the Full_EKT_Field		The EKT Field uses the format defined below for the FullEKTField and
	and Short_EKT_Field.		ShortEKTField.
	0 1 2 3		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 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: :		: :
	: EKT Ciphertext :		: EKT Ciphertext :
	: :		: :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Security Parameter Index | Length | 2		| Security Parameter Index | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|0 0 0 0 0 0 1 0|
			+-+-+-+-+-+-+-+-+
	Figure 1: Full EKT Field format		Figure 1: Full EKT Field format
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0|0|		|0 0 0 0 0 0 0 0|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 2: Short EKT Field format		Figure 2: Short EKT Field format
	TODO: move following syntax to ABNF. Move name of Short to Empty.		The following shows the syntax of the EKTField expressed in ABNF
	Move name of Full to EncryptedKey. Drop extra EKT.		[RFC5234]. The EKTField is added to the end of an SRTP or SRTCP
			packet. The EKTCiphertext is computed by encrypting the EKTPlaintext
			using the EKTKey. Future extensions to the EKTField MUST conform to
			the syntax of ExtensionEKTField.
	EKT_Msg_Type_Full = 2 ; 8 bits		BYTE = %x00-FF
	EKT_Msg_Length ; 16 bits. length in octets including type and length
	EKT_Plaintext = SRTP_Master_Key || SSRC || ROC || TTL		EKTMsgTypeFull = %x02
			EKTMsgTypeShort = %x00
			EKTMsgTypeExtension = %x03-FF
	EKT_Ciphertext = EKT_Encrypt(EKT_Key, EKT_Plaintext)		EKTMsgLength = 2BYTE;
	Full_EKT_Field = EKT_Ciphertext || SPI ||		SRTPMasterKeyLength = BYTE
	EKT_Msg_Length || EKT_Msg_Type_Full		SRTPMasterKey = 1*256BYTE
			SSRC = 4BYTE; SSRC from RTP
			ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC
	Short_EKT_Field = '00000000'		EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
	Figure 3: EKT data formats		EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
			SPI = 2BYTE
			FullEKTField = EKTCiphertext SPI EKTMsgLength EKTMsgTypeFull
			ShortEKTField = EKTMsgTypeShort
			ExtensionData = 1*1024BYTE
			ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
			EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
			Figure 3: EKTField Syntax
	These fields and data elements are defined as follows:		These fields and data elements are defined as follows:
	EKT_Plaintext: The data that is input to the EKT encryption		EKTPlaintext: The data that is input to the EKT encryption
	operation. This data never appears on the wire, and is used only		operation. This data never appears on the wire, and is used only
	in computations internal to EKT. This is the concatenation of the		in computations internal to EKT. This is the concatenation of the
	SRTP Master Key, the SSRC, ROC, and the TTL.		SRTP Master Key, the SSRC, and the ROC.
	EKT_Ciphertext: The data that is output from the EKT encryption		EKTCiphertext: The data that is output from the EKT encryption
	operation, described in Section 2.3. This field is included in		operation, described in Section 2.3. This field is included in
	SRTP packets when EKT is in use. The length of this field is		SRTP packets when EKT is in use.
	variable, and is equal to the ciphertext size N defined in
	Section 2.3. Note that the length of the field is inferable from
	the SPI field, since the SPI will indicate the cipher being used
	and thus the size.
	SRTP_Master_Key: On the sender side, the SRTP Master Key associated		SRTPMasterKey: On the sender side, the SRTP Master Key associated
	with the indicated SSRC. The length of this field depends on the		with the indicated SSRC.
	cipher suite negotiated during call setup for SRTP or SRTCP.
			SRTPMasterKeyLength: The length of the SRTPMasterKey. This depends
			on the cipher suite negotiated for SRTP using [RFC3264] SDP Offer/
			Answer for the SRTP.
	SSRC: On the sender side, this field is the SSRC for this SRTP		SSRC: On the sender side, this field is the SSRC for this SRTP
	source. The length of this field is 32 bits.		source. The length of this field is 32 bits.
	Rollover Counter (ROC): On the sender side, this field is set to the		Rollover Counter (ROC): On the sender side, this field is set to the
	current value of the SRTP rollover counter in the SRTP context		current value of the SRTP rollover counter in the SRTP context
	associated with the SSRC in the SRTP or SRTCP packet. The length		associated with the SSRC in the SRTP or SRTCP packet. The length
	of this field is 32 bits.		of this field is 32 bits.
	Time to Live (TTL): The maximum amount of time that this key can be
	used. A unsigned 16 bit integer representing duration in seconds.
	The SRTP Master key in this message MUST NOT be used for
	encrypting or decrypting information after this time. Open Issue:
	does this need to be absolute time not duration? TODO: discuss in
	security section.
	Security Parameter Index (SPI): This field indicates the appropriate		Security Parameter Index (SPI): This field indicates the appropriate
	EKT Key and other parameters for the receiver to use when		EKT Key and other parameters for the receiver to use when
	processing the packet. Each time a different EKT Key is received,		processing the packet. The length of this field is 16 bits. The
	it will have a larger SPI than the previous key (after taking
	rollover into account). The length of this field is 16 bits. The
	parameters identified by this field are:		parameters identified by this field are:
	* The EKT cipher used to process the packet.		* The EKT cipher used to process the packet.
	* The EKT Key used to process the packet.		* The EKT Key used to process the packet.
	* The SRTP Master Salt associated with any Master Key encrypted		* The SRTP Master Salt associated with any Master Key encrypted
	with this EKT Key.		with this EKT Key. The Master Salt is communicated separately,
			via signaling, typically along with the EKTKey.
	Together, these data elements are called an EKT parameter set.		Together, these data elements are called an EKT parameter set.
	Within each SRTP session, each distinct EKT parameter set that may		Each distinct EKT parameter set that is used MUST be associated
	be used MUST be associated with a distinct SPI value, to avoid		with a distinct SPI value to avoid ambiguity.
	ambiguity.
	EKT_Msg_Length All EKT message other that Short EKT Field must have		EKTMsgLength All EKT message other that ShortEKTField must have a
	a length as the second from last elements. This is the length in		length as second from the last element. This is the length in
	octets of the full EKT message including this length field and the		octets of either the FullEKTField/ExtensionEKTField including this
	following message type.		length field and the following message type.
	Message Type The last byte is used to indicate the type of the		Message Type The last byte is used to indicate the type of the
	Field. This MUST be 2 in the Full EKT Field format and 0 in Short		EKTField. This MUST be 2 in the FullEKTField format and 0 in
	EKT Field. Future specifications that define new types SHOULD use		ShortEKTField format. Values less than 64 are mandatory to
	even values until all the even code points are consumed to avoid		understand and the whole EKTField SHOULD be discarded if it
	conflicts with pre standards version of EKT that have been		contains message type value that is less than 64 and is not
	deployed. Values less than 64 are mandatory to understand the		implemented.
	whole EKT field SHOULD be discarded if it contains message type
	value that is less than 64 and not implemented.
	TODO - add IANA registry for Message Type.
	2.2. Packet Processing and State Machine		2.2. Packet Processing and State Machine
	At any given time, each SRTP/SRTCP source (SSRC) has associated with		At any given time, each SRTP/SRTCP source has associated with it a
	it a single EKT parameter set. This parameter set is used to process		single EKT parameter set. This parameter set is used to process all
	all outbound packets, and is called the outbound parameter set for		outbound packets, and is called the outbound parameter set for that
	that SSRC. There may be other EKT parameter sets that are used by		SSRC. There may be other EKT parameter sets that are used by other
	other SRTP/SRTCP sources in the same session, including other SRTP/		SRTP/SRTCP sources in the same session, including other SRTP/SRTCP
	SRTCP sources on the same endpoint (e.g., one endpoint with voice and		sources on the same endpoint (e.g., one endpoint with voice and video
	video might have two EKT parameter sets, or there might be multiple		might have two EKT parameter sets, or there might be multiple video
	video sources on an endpoint each with their own EKT parameter set).		sources on an endpoint each with their own EKT parameter set). All
	All of the received EKT parameter sets SHOULD be stored by all of the		of the received EKT parameter sets SHOULD be stored by all of the
	participants in an SRTP session, for use in processing inbound SRTP		participants in an SRTP session, for use in processing inbound SRTP
	and SRTCP traffic.		and SRTCP traffic.
	All SRTP master keys MUST NOT be re-used, MUST be randomly generated		Either the FullEKTField or ShortEKTField is appended at the tail end
	according to [RFC4086], and MUST NOT be equal to or derived from		of all SRTP packets.
	other SRTP master keys.
	Either the Full_EKT_Field or Short_EKT_Field is appended at the tail
	end of all the SRTP packet.
	2.2.1. Outbound Processing		2.2.1. Outbound Processing
	See Section 2.6 which describes when to send an EKT packet with a		See Section 2.6 which describes when to send an EKT packet with a
	Full EKT Field. If a Full EKT Field is not being sent, then a Short		FullEKTField. If a FullEKTField is not being sent, then a
	EKT Field needs to be sent so the receiver can correctly determine		ShortEKTField needs to be sent so the receiver can correctly
	how to process the packet.		determine how to process the packet.
	When an SRTP packet is to be sent with a Full EKT Field, the EKT		When an SRTP packet is to be sent with a FullEKTField, the EKTField
	field for that packet is created as follows, or uses an equivalent		for that packet is created as follows, or uses an equivalent set of
	set of steps. The creation of the EKT field MUST precede the normal		steps. The creation of the EKTField MUST precede the normal SRTP
	SRTP packet processing.		packet processing.
	1. The Security Parameter Index field is set to the value of the		1. The Security Parameter Index (SPI) field is set to the value of
	Security Parameter Index that is associated with the outbound		the Security Parameter Index that is associated with the outbound
	parameter set.		parameter set.
	2. The EKT_Plaintext field is computed from the SRTP Master Key,		2. The EKTPlaintext field is computed from the SRTP Master Key,
	SSRC, and ROC fields, as shown in Section 2.1. The ROC, SRTP		SSRC, and ROC fields, as shown in Section 2.1. The ROC, SRTP
	Master Key, and SSRC used in EKT processing SHOULD be the same as		Master Key, and SSRC used in EKT processing SHOULD be the same as
	the one used in the SRTP processing.		the one used in the SRTP processing.
	3. The EKT_Ciphertext field is set to the ciphertext created by		3. The EKTCiphertext field is set to the ciphertext created by
	encrypting the EKT_Plaintext with the EKT cipher, using the EKT		encrypting the EKTPlaintext with the EKT cipher, using the EKTKey
	Key as the encryption key. The encryption process is detailed in		as the encryption key. The encryption process is detailed in
	Section 2.3.		Section 2.3.
	4. Then the Full EKT Field is formed using the EKT Ciphertext and		4. Then the FullEKTField is formed using the EKTCiphertext and the
	the SPI associated with the EKT Key used above. The computed		SPI associated with the EKTKey used above. Also appended are the
	value of the Full EKT Field is written into the packet.		Length and EKTMEsgTypeFull elements.
	When a packet is sent with the Short EKT Field, the Short EKF Field		Note: the value of the EKT Ciphertext field is identical in
	is simply appended to the packet.		successive packets protected by the same EKTKey and SRTP
			master key. This value MAY be cached by an SRTP sender to
			minimize computational effort.
			The computed value of the FullEKTField is written into the
			packet.
			When a packet is sent with the Short EKT Field, the ShortEKFField is
			simply appended to the packet.
	2.2.2. Inbound Processing		2.2.2. Inbound Processing
	Inbound EKT processing MUST take place prior to the usual SRTP or		When receiving a packet on a RTP stream where EKT was negotiated, the
	SRTCP processing. The following steps show processing as packets are		following steps are applied for each received packet.
	received in order.
	1. The final byte is checked to determine which EKT format is in		1. The final byte is checked to determine which EKT format is in
	use. When an SRTP or SRTCP packet contains a Short EKT Field,		use. When an SRTP or SRTCP packet contains a ShortEKTField, the
	the Short EKT Field is removed from the packet then normal SRTP		ShortEKTField is removed from the packet then normal SRTP or
	or SRTCP processing occurs. If the packet contains a Full EKT		SRTCP processing occurs. If the packet contains a FullEKTField,
	Field, then processing continues as described below.		then processing continues as described below.
	2. The combination of the SSRC and the Security Parameter Index		2. The Security Parameter Index (SPI) field is used to find which
	(SPI) field is used to find which EKT parameter set should be		EKT parameter set to be used when processing the packet. If
	used when processing the packet. If there is no matching SPI,		there is no matching SPI, then the verification function MUST
	then the verification function MUST return an indication of		return an indication of authentication failure, and the steps
	authentication failure, and the steps described below are not		described below are not performed. The EKT parameter set
	performed. EKT parameter set contains the EKT Key, EKT Cipher,		contains the EKTKey, EKTCipher, and SRTP Master Salt.
	and SRTP Master Salt.
	3. The EKT Ciphertext authentication is checked and it is decrypted,		3. The EKTCiphertext authentication is checked and it is decrypted,
	as described in Section 2.3, using the EKT Key and EKT Cipher		as described in Section 2.3, using the EKTKey and EKTCipher found
	found in the previous step. If the EKT decryption operation		in the previous step. If the EKT decryption operation returns an
	returns an authentication failure, then the packet processing		authentication failure, then the packet processing stops.
	stops.
	4. The resulting EKT Plaintext is parsed as described in		4. The resulting EKTPlaintext is parsed as described in Section 2.1,
	Section 2.1, to recover the SRTP Master Key, SSRC, and ROC		to recover the SRTP Master Key, SSRC, and ROC fields. The Master
	fields. The Master Salt that is assocted with the EKT Keys used		Salt that is associated with the EKTKey is also retrieved. If
	to do the decription is also retreived.		the value of the srtp_master_salt sent as part of the EKTkey is
			longer than needed by SRTP, then it is truncated by taking the
			first N bytes from the srtp_master_salt field.
	5. The SRTP Master Key, ROC, and Master Salt from the prevous step		5. The SRTP Master Key, ROC, and SRTP Master Salt from the previous
	are saved in a map indexed by the SSRC found in the EKT Plaintext		step are saved in a map indexed by the SSRC found in the
	and can be used for any future crypto operations for inbound or		EKTPlaintext and can be used for any future crypto operations on
	outbound packets with the that SSRC. Outbound packets SHOULD		the inbound packets with that SSRC. Outbound packets SHOULD
	continue to use the old key for 250 ms after receipt of the new		continue to use the old SRTP Master Key for 250 ms after sending
	key. This gives all the receivers in the system time to get the		any new key. This gives all the receivers in the system time to
	new key before they start receiving media encrypted with the new		get the new key before they start receiving media encrypted with
	key. The key MUST NOT be used beyond the lifetime found in the		the new key.
	TTL field.
	6. At this point, EKT processing has successfully completed, and the		6. At this point, EKT processing has successfully completed, and the
	normal SRTP or SRTCP processing takes place including replay		normal SRTP or SRTCP processing takes place including replay
	protection.		protection.
	Implementation note: the receiver may want to have a sliding window		2.2.2.1. Implementation Notes for Inbound Processing
	to retain old SRTP master keys (and related context) for some brief
	period of time, so that out of order packets can be processed as well		The value of the EKTCiphertext field is identical in successive
	as packets sent during the time keys are changing.		packets protected by the same EKT parameter set and the same SRTP
			master key, and ROC. This ciphertext value MAY be cached by an SRTP
			receiver to minimize computational effort by noting when the SRTP
			master key is unchanged and avoiding repeating the above steps.
			The receiver may want to have a sliding window to retain old SRTP
			master keys (and related context) for some brief period of time, so
			that out of order packets can be processed as well as packets sent
			during the time keys are changing.
	2.3. Ciphers		2.3. Ciphers
	EKT uses an authenticated cipher to encrypt and authenticate the EKT		EKT uses an authenticated cipher to encrypt and authenticate the
	Plaintext. We first specify the interface to the cipher, in order to		EKTPlaintext. We first specify the interface to the cipher, in order
	abstract the interface away from the details of that function. We		to abstract the interface away from the details of that function. We
	then define the cipher that is used in EKT by default. The default		then define the cipher that is used in EKT by default. The default
	cipher described in Section 2.3.1 MUST be implemented, but another		cipher described in Section 2.3.1 MUST be implemented, but another
	cipher that conforms to this interface MAY be used, in which case its		cipher that conforms to this interface MAY be used, in which case its
	use MUST be coordinated by external means (e.g., key management).		use MUST be coordinated by external means (e.g., key management).
	An EKT cipher consists of an encryption function and a decryption		An EKTCipher consists of an encryption function and a decryption
	function. The encryption function E(K, P) takes the following		function. The encryption function E(K, P) takes the following
	inputs:		inputs:
	o a secret key K with a length of L bytes, and		o a secret key K with a length of L bytes, and
	o a plaintext value P with a length of M bytes.		o a plaintext value P with a length of M bytes.
	The encryption function returns a ciphertext value C whose length is		The encryption function returns a ciphertext value C whose length is
	N bytes, where N is at least M. The decryption function D(K, C)		N bytes, where N may be larger than M. The decryption function D(K,
	takes the following inputs:		C) takes the following inputs:
	o a secret key K with a length of L bytes, and		o a secret key K with a length of L bytes, and
	o a ciphertext value C with a length of N bytes.		o a ciphertext value C with a length of N bytes.
	The decryption function returns a plaintext value P that is M bytes		The decryption function returns a plaintext value P that is at least
	long, or returns an indication that the decryption operation failed		M bytes long, or returns an indication that the decryption operation
	because the ciphertext was invalid (i.e. it was not generated by the		failed because the ciphertext was invalid (i.e. it was not generated
	encryption of plaintext with the key K).		by the encryption of plaintext with the key K).
	These functions have the property that D(K, E(K, P)) = P for all		These functions have the property that D(K, E(K, P)) = ( P
	values of K and P. Each cipher also has a limit T on the number of		concatenated with optional padding) for all values of K and P. Each
	times that it can be used with any fixed key value. For each key,		cipher also has a limit T on the number of times that it can be used
	the encryption function MUST NOT be invoked on more than T distinct		with any fixed key value. The EKTKey MUST NOT be used more that T
	values of P, and the decryption function MUST NOT be invoked on more		times.
	than T distinct values of C.
	Security requirements for EKT ciphers are discussed in Section 5.		Security requirements for EKT ciphers are discussed in Section 4.
	2.3.1. The Default Cipher		2.3.1. Ciphers
	The default EKT Cipher is the Advanced Encryption Standard (AES) Key		The default EKT Cipher is the Advanced Encryption Standard (AES) Key
	Wrap with Padding [RFC5649] algorithm. It requires a plaintext		Wrap with Padding [RFC5649] algorithm. It requires a plaintext
	length M that is at least one octet, and it returns a ciphertext with		length M that is at least one octet, and it returns a ciphertext with
	a length of N = M + 8 octets. It can be used with key sizes of L =		a length of N = M + (M mod 8) + 8 octets. It can be used with key
	16, and 32 octets, and its use with those key sizes is indicated as		sizes of L = 16, and L = 32 octets, and its use with those key sizes
	AESKW_128, or AESKW_256, respectively. The key size determines the		is indicated as AESKW128, or AESKW256, respectively. The key size
	length of the AES key used by the Key Wrap algorithm. With this		determines the length of the AES key used by the Key Wrap algorithm.
	cipher, T=2^48.		With this cipher, T=2^48.
	length of length of		+----------+----+------+
	SRTP EKT EKT EKT length of		| Cipher | L | T |
	transform transform plaintext ciphertext Full EKT Field		+----------+----+------+
	--------- ------------ --------- ---------- --------------		| AESKW128 | 16 | 2^48 |
	AES-128 AESKW_128 26 40 42		| | | |
	AES-256 AESKW_256 42 56 58		| AESKW256 | 32 | 2^48 |
			+----------+----+------+
	Figure 4: AESKW Table		Table 1: EKT Ciphers
	As AES-128 is the mandatory to implement transform in SRTP [RFC3711],		As AES-128 is the mandatory to implement transform in SRTP [RFC3711],
	AESKW_128 MUST be implemented for EKT.		AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented.
	For all the SRTP transforms listed in the table, the corresponding
	EKT transform MUST be used, unless a stronger EKT transform is
	negotiated by key management.
	2.3.2. Other EKT Ciphers		2.3.2. Defining New EKT Ciphers
	Other specifications may extend this one by defining other EKT		Other specifications may extend this document by defining other
	ciphers per Section 7. This section defines how those ciphers		EKTCiphers as described in Section 5. This section defines how those
	interact with this specification.		ciphers interact with this specification.
	An EKT cipher determines how the EKT Ciphertext field is written, and		An EKTCipher determines how the EKTCiphertext field is written, and
	how it is processed when it is read. This field is opaque to the		how it is processed when it is read. This field is opaque to the
	other aspects of EKT processing. EKT ciphers are free to use this		other aspects of EKT processing. EKT ciphers are free to use this
	field in any way, but they SHOULD NOT use other EKT or SRTP fields as		field in any way, but they SHOULD NOT use other EKT or SRTP fields as
	an input. The values of the parameters L, M, N, and T MUST be		an input. The values of the parameters L, and T MUST be defined by
	defined by each EKT cipher, and those values MUST be inferable from		each EKTCipher.
	the EKT parameter set.
	2.4. Synchronizing Operation		2.4. Synchronizing Operation
	If a source has its EKT key changed by the key management, it MUST		If a source has its EKTKey changed by the key management, it MUST
	also change its SRTP master key, which will cause it to send out a		also change its SRTP master key, which will cause it to send out a
	new Full EKT Field. This ensures that if key management thought the		new FullEKTField. This ensures that if key management thought the
	EKT key needs changing (due to a participant leaving or joining) and		EKTKey needs changing (due to a participant leaving or joining) and
	communicated that in key management to a source, the source will also		communicated that to a source, the source will also change its SRTP
	change its SRTP master key, so that traffic can be decrypted only by		master key, so that traffic can be decrypted only by those who know
	those who know the current EKT key.		the current EKTKey.
	2.5. Transport		2.5. Transport
	EKT SHOULD be used over SRTP, and other specification MAY define how		EKT SHOULD be used over SRTP, and other specification MAY define how
	to use it over SRTCP. SRTP is preferred because it shares fate with		to use it over SRTCP. SRTP is preferred because it shares fate with
	transmitted media, because SRTP rekeying can occur without concern		transmitted media, because SRTP rekeying can occur without concern
	for RTCP transmission limits, and to avoid SRTCP compound packets		for RTCP transmission limits, and to avoid SRTCP compound packets
	with RTP translators and mixers.		with RTP translators and mixers.
	2.6. Timing and Reliability Consideration		2.6. Timing and Reliability Consideration
	A system using EKT learns the SRTP master keys distributed with Full		A system using EKT learns the SRTP master keys distributed with
	EKT Fields send with the SRTP, rather than with call signaling. A		FullEKTFields sent with the SRTP, rather than with call signaling. A
	receiver can immediately decrypt an SRTP provided the SRTP packet		receiver can immediately decrypt an SRTP packet, provided the SRTP
	contains a Full EKT Field.		packet contains a Full EKT Field.
	This section describes how to reliably and expediently deliver new		This section describes how to reliably and expediently deliver new
	SRTP master keys to receivers.		SRTP master keys to receivers.
	There are three cases to consider. The first case is a new sender		There are three cases to consider. The first case is a new sender
	joining a session which needs to communicate its SRTP master key to		joining a session which needs to communicate its SRTP master key to
	all the receivers. The second case is a sender changing its SRTP		all the receivers. The second case is a sender changing its SRTP
	master key which needs to be communicated to all the receivers. The		master key which needs to be communicated to all the receivers. The
	third case is a new receiver joining a session already in progress		third case is a new receiver joining a session already in progress
	which needs to know the sender's SRTP master key.		which needs to know the sender's SRTP master key.
	New sender: A new sender SHOULD send a packet containing the Full EKT		The three cases are:
	Field as soon as possible, always before or coincident with sending
	its initial SRTP packet. To accommodate packet loss, it is
	RECOMMENDED that three consecutive packets contain the Full EKT Field
	be transmitted.
	Rekey: By sending EKT over SRTP, the rekeying event shares fate with		New sender: A new sender SHOULD send a packet containing the
	the SRTP packets protected with that new SRTP master key.		FullEKTField as soon as possible, always before or coincident with
			sending its initial SRTP packet. To accommodate packet loss, it
			is RECOMMENDED that three consecutive packets contain the Full EKT
			Field be transmitted.
	New receiver: When a new receiver joins a session it does not need to		Rekey: By sending EKT over SRTP, the rekeying event shares fate with
	communicate its sending SRTP master key (because it is a receiver).		the SRTP packets protected with that new SRTP master key. To
	When a new receiver joins a session the sender is generally unaware		accommodate packet loss, it is RECOMMENDED that three consecutive
	of the receiver joining the session. Thus, senders SHOULD		packets contain the FullEKTField be transmitted.
	periodically transmit the Full EKT Field. That interval depends on
	how frequently new receivers join the session, the acceptable delay		New receiver: When a new receiver joins a session it does not need
	before those receivers can start processing SRTP packets, and the		to communicate its sending SRTP master key (because it is a
	acceptable overhead of sending the Full EKT Field. The RECOMMENDED		receiver). When a new receiver joins a session the sender is
	frequency is the same as the key frame frequency if sending video and		generally unaware of the receiver joining the session. Thus,
	every 100ms for audio.		senders SHOULD periodically transmit the FullEKTField. That
			interval depends on how frequently new receivers join the session,
			the acceptable delay before those receivers can start processing
			SRTP packets, and the acceptable overhead of sending the FullEKT
			Field. If sending audio and video, the RECOMMENDED frequency is
			the same as the rate of intra coded video frames. If only sending
			audio, the RECOMMENDED frequency is every 100ms.
	3. Use of EKT with DTLS-SRTP		3. Use of EKT with DTLS-SRTP
	This document defines an extension to DTLS-SRTP called Key Transport.		This document defines an extension to DTLS-SRTP called SRTP EKT Key
	The EKT with the DTLS-SRTP Key Transport enables secure transport of		Transport which enables secure transport of EKT keying material from
	EKT keying material from one DTLS-SRTP peer to another. This enables		one DTLS-SRTP peer to another. This allows those peers to process
	those peers to process EKT keying material in SRTP (or SRTCP) and		EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP
	retrieve the embedded SRTP keying material. This combination of		keying material. This combination of protocols is valuable because
	protocols is valuable because it combines the advantages of DTLS		it combines the advantages of DTLS, which has strong authentication
	(strong authentication of the endpoint and flexibility) with the		of the endpoint and flexibility, along with allowing secure
	advantages of EKT (allowing secure multiparty RTP with loose		multiparty RTP with loose coordination and efficient communication of
	coordination and efficient communication of per-source keys).		per-source keys.
	3.1. DTLS-SRTP Recap		3.1. DTLS-SRTP Recap
	DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers		DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers
	to exchange keying material, algorithms, and parameters for SRTP.		to exchange keying material, algorithms, and parameters for SRTP.
	The SRTP flow operates over the same transport as the DTLS-SRTP		The SRTP flow operates over the same transport as the DTLS-SRTP
	exchange (i.e., the same 5-tuple). DTLS-SRTP combines the		exchange (i.e., the same 5-tuple). DTLS-SRTP combines the
	performance and encryption flexibility benefits of SRTP with the		performance and encryption flexibility benefits of SRTP with the
	flexibility and convenience of DTLS-integrated key and association		flexibility and convenience of DTLS-integrated key and association
	management. DTLS-SRTP can be viewed in two equivalent ways: as a new		management. DTLS-SRTP can be viewed in two equivalent ways: as a new
	key management method for SRTP, and a new RTP-specific data format		key management method for SRTP, and a new RTP-specific data format
	for DTLS.		for DTLS.
	3.2. EKT Extensions to DTLS-SRTP		3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP
	This document adds a new TLS negotiated extension called "ekt". This		This document defines a new TLS negotiated extension called
	adds a new TLS content type, EKT, and a new negotiated extension EKT.		"srtp_ekt_key_transport"and a new TLS content type called EKTMessage.
	The DTLS server includes "ekt" in its TLS ServerHello message. If a
	DTLS client includes "ekt" in its ClientHello, but does not receive
	"ekt" in the ServerHello, the DTLS client MUST NOT send DTLS packets
	with the "ekt" content-type.
	Using the syntax described in DTLS [RFC6347], the following		Using the syntax described in DTLS [RFC6347], the following
	structures are used:		structures are used:
	enum {		enum {
	ekt_key(0),		reserved(0),
	ekt_key_ack(1),		aeskw_128(1),
	ekt_key_error(254),		aeskw_256(3),
	(255)		} EKTCipherType;
	} SRTPKeyTransportType;
	struct {		struct {
	SRTPKeyTransportType keytrans_type;		EKTCipherType ekt_ciphers<0..254>;
	uint24 length;		} SupportedEKTCiphers;
	uint16 message_seq;
	uint24 fragment_offset;
	uint24 fragment_length;
	select (SRTPKeyTransportType) {
	case ekt_key:
	EKTkey;
	};
	} KeyTransport;
	enum {		struct {
	RESERVED(0),		EKTCipherType ekt_cipher;
	AESKW_128(1),		uint ekt_key_value<1..256>;
	AESKW_256(3),		uint srtp_master_salt<1..256>;
	} ektcipher;		uint16 ekt_spi;
			uint24 ekt_ttl;
			} EKTkey;
	struct {		enum {
	ektcipher EKT_Cipher;		ekt_key(0),
	uint EKT_Key_Value<1..256>;		ekt_key_ack(1),
	uint EKT_Master_Salt<1..256>;		ekt_key_error(254),
	uint16 EKT_SPI;		(255)
	} EKTkey;		} EKTMessageType;
	Figure 5: Additional TLS Data Structures		struct {
			EKTMessageType ekt_message_type;
			select (EKTMessage.ekt_message_type) {
			case ekt_key:
			EKTKey;
			} message;
			} EKTMessage;
			Figure 4: Additional TLS Data Structures
			If a DTLS client includes "srtp_ekt_key_transport" in its
			ClientHello, then a DTLS server that supports this extensions will
			includes "srtp_ekt_key_transport" in its ServerHello message. If a
			DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but
			does not receive "srtp_ekt_key_transport" in the ServerHello, the
			DTLS client MUST NOT send DTLS EKTMessage messages.
			When a DTLS client sends the "srtp_ekt_key_transport" in its
			ClientHello message, it MUST include the SupportedEKTCiphers as the
			extension_data for the extension, listing the EKTCipherTypes the
			client is willing to use in preference order, with the most preferred
			version first. When the server responds in the
			"srtp_ekt_key_transport" in its ServerHello message, it must include
			a SupportedEKTCiphers list that selects a single EKTCipherType to use
			(selected from the list provided by the client) or it returns an
			empty list to indicate there is no matching EKTCipherType in the
			clients list that the server is also willing to use. The value to be
			used in the EKTCipherType for future extensions that define new
			ciphers is the value from the "EKT Ciphers Type" IANA registry
			defined in Section 5.2.
			The figure above defines the contents for a new TLS content type
			called EKTMessage which is registered in Section 5.4. The EKTMessage
			above is used as the opaque fragment in the TLSPlaintext structure
			defined in Section 6.2.1 of [RFC5246] and the "srtp_ekt_message" as
			the content type. The "srtp_ekt_message" content type is defined and
			registered in Section 5.3.
			ekt_ttl: The maximum amount of time, in seconds, that this
			ekt_key_value can be used. The ekt_key_value in this message MUST
			NOT be used for encrypting or decrypting information after the TTL
			expires.
			When the Server wishes to provide a new EKT Key, it can send
			EKTMessage containing an EKTKey with the new key information. The
			client MUST respond with an EKTMessage of type ekt_key_ack, if the
			EKTKey was successfully processed and stored or respond with the the
			ekt_key_error EKTMessage otherwise.
	The diagram below shows a message flow of DTLS client and DTLS server		The diagram below shows a message flow of DTLS client and DTLS server
	using the DTLS-SRTP Key Transport extension.		using the DTLS-SRTP Key Transport extension.
	Client Server		Client Server
	ClientHello + use_srtp + EKT		ClientHello + use_srtp + srtp_ekt_key_trans
	-------->		-------->
	ServerHello + use_srtp + EKT		ServerHello+use_srtp+srtp_ekt_key_trans
	Certificate*		Certificate*
	ServerKeyExchange*		ServerKeyExchange*
	CertificateRequest*		CertificateRequest*
	<-------- ServerHelloDone		<-------- ServerHelloDone
	Certificate*		Certificate*
	ClientKeyExchange		ClientKeyExchange
	CertificateVerify*		CertificateVerify*
	[ChangeCipherSpec]		[ChangeCipherSpec]
	Finished -------->		Finished -------->
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	ekt_key <--------		ekt_key <--------
	ACK -------->		ekt_key_ack -------->
	SRTP packets <-------> SRTP packets		SRTP packets <-------> SRTP packets
	SRTP packets <-------> SRTP packets		SRTP packets <-------> SRTP packets
	ekt_key (rekey) <-------		ekt_key (rekey) <-------
	ACK -------->		ekt_key_ack -------->
	SRTP packets <-------> SRTP packets		SRTP packets <-------> SRTP packets
	SRTP packets <-------> SRTP packets		SRTP packets <-------> SRTP packets
	Figure 6: Handshake Message Flow		Figure 5: DTLS/SRTP Message Flow
	3.3. Offer/Answer Considerations		3.3. Offer/Answer Considerations
	When using EKT with DTLS-SRTP, the negotiation to use EKT is done at		When using EKT with DTLS-SRTP, the negotiation to use EKT is done at
	the DTLS handshake level and does not change the [RFC3264] Offer /		the DTLS handshake level and does not change the [RFC3264] Offer /
	Answer messaging.		Answer messaging.
	4. Sending the DTLS EKT_Key Reliably		3.4. Sending the DTLS EKT_Key Reliably
	The DTLS ekt_key is sent using the retransmiions specified in		The DTLS ekt_key is sent using the retransmissions specified in
	Section 4.2.4. of DTLS [RFC6347].		Section 4.2.4. of DTLS [RFC6347].
	5. Security Considerations		4. Security Considerations
	EKT inherits the security properties of the DTLS-SRTP (or other)		EKT inherits the security properties of the DTLS-SRTP (or other)
	keying it uses.		keying it uses.
	With EKT, each SRTP sender and receiver MUST generate distinct SRTP		With EKT, each SRTP sender and receiver MUST generate distinct SRTP
	master keys. This property avoids any security concern over the re-		master keys. This property avoids any security concern over the re-
	use of keys, by empowering the SRTP layer to create keys on demand.		use of keys, by empowering the SRTP layer to create keys on demand.
	Note that the inputs of EKT are the same as for SRTP with key-		Note that the inputs of EKT are the same as for SRTP with key-
	sharing: a single key is provided to protect an entire SRTP session.		sharing: a single key is provided to protect an entire SRTP session.
	However, EKT remains secure even when SSRC values collide.		However, EKT remains secure even when SSRC values collide.
			SRTP master keys MUST be randomly generated, and [RFC4086] offers
			some guidance about random number generation. SRTP master keys MUST
			NOT be re-used for any other purpose, and SRTP master keys MUST NOT
			be derived from other SRTP master keys.
	The EKT Cipher includes its own authentication/integrity check. For		The EKT Cipher includes its own authentication/integrity check. For
	an attacker to successfully forge a full EKT packet, it would need to		an attacker to successfully forge a full EKT packet, it would need to
	defeat the authentication mechanisms of the EKT Cipher authentication		defeat the authentication mechanisms of the EKT Cipher authentication
	mechanism.		mechanism.
	The presence of the SSRC in the EKT_Plaintext ensures that an		The presence of the SSRC in the EKTPlaintext ensures that an attacker
	attacker cannot substitute an EKT_Ciphertext from one SRTP stream		cannot substitute an EKTCiphertext from one SRTP stream into another
	into another SRTP stream.		SRTP stream.
	An attacker who tampers with the bits in Full_EKT_Field can prevent		An attacker who tampers with the bits in FullEKTField can prevent the
	the intended receiver of that packet from being able to decrypt it.		intended receiver of that packet from being able to decrypt it. This
	This is a minor denial of service vulnerability.		is a minor denial of service vulnerability.
	An attacker could send packets containing a Full EKT Field, in an		An attacker could send packets containing a Full EKT Field, in an
	attempt to consume additional CPU resources of the receiving system		attempt to consume additional CPU resources of the receiving system
	by causing the receiving system will decrypt the EKT ciphertext and		by causing the receiving system will decrypt the EKT ciphertext and
	detect an authentication failure		detect an authentication failure. In some cases, caching the
			previous values of the Ciphertext as described in Section 2.2.2.1
			helps mitigate this issue.
	EKT can rekey an SRTP stream until the SRTP rollover counter (ROC)		Each EKT cipher specifies a value T that is the maximum number of
	needs to roll over. EKT does not extend SRTP's rollover counter		times a given key can be used. An endpoint MUST NOT send more than T
	(ROC), and like SRTP itself EKT cannot properly handle a ROC		Full EKT Field using the same EKTKey. In addition, the EKTKey MUST
	rollover. Thus even if using EKT, new (master or session) keys need		NOT be used beyond the lifetime provided by the TTL described in
	to be established after 2^48 packets are transmitted in a single SRTP		Section 3.2.
	stream as described in Section 3.3.1 of [RFC3711]. Due to the
	relatively low packet rates of typical RTP sessions, this is not
	expected to be a burden.
	The confidentiality, integrity, and authentication of the EKT cipher		The confidentiality, integrity, and authentication of the EKT cipher
	MUST be at least as strong as the SRTP cipher.		MUST be at least as strong as the SRTP cipher and at least as strong
			as the DTLS-SRTP ciphers.
	Part of the EKT_Plaintext is known, or easily guessable to an		Part of the EKTPlaintext is known, or easily guessable to an
	attacker. Thus, the EKT Cipher MUST resist known plaintext attacks.		attacker. Thus, the EKT Cipher MUST resist known plaintext attacks.
	In practice, this requirement does not impose any restrictions on our		In practice, this requirement does not impose any restrictions on our
	choices, since the ciphers in use provide high security even when		choices, since the ciphers in use provide high security even when
	much plaintext is known.		much plaintext is known.
	An EKT cipher MUST resist attacks in which both ciphertexts and		An EKT cipher MUST resist attacks in which both ciphertexts and
	plaintexts can be adaptively chosen and adversaries that can query		plaintexts can be adaptively chosen and adversaries that can query
	both the encryption and decryption functions adaptively.		both the encryption and decryption functions adaptively.
	6. Open Issues		In some systems, when a member of a conference leaves the
			conferences, the conferences is rekeyed so that member no longer has
			the key. When changing to a new EKTKey, it is possible that the
			attacker could block the EKTKey message getting to a particular
			endpoint and that endpoint would keep sending media encrypted using
			the old key. To mitigate that risk, the lifetime of the EKTKey
			SHOULD be limited using the ekt_ttl.
	What length should the SPI be?		5. IANA Considerations
	Should we limit the number of saved SPI for a given SSRC? Or limit
	the lifetime of old ones after a new one is received? At some level
	this may not matter because even if the a SRTP packet is injected
	with an old value, it will be discards by the RTP stack for being
	old. It is more important that new things are encrypted with the
	most recent EKT Key.
	How many bits to differentiate different types of packets and allow		5.1. EKT Message Types
	for extensibility?
	Given the amount of old EKT deployed, should the Full EKT use a a		IANA is requested to create a new registry for "EKT Messages Types".
	different code point than the "1" at the end?		The initial values in this registry are:
	Do we need AES-192?		+--------------+-------+---------------+
			| Message Type | Value | Specification |
			+--------------+-------+---------------+
			| Short | 0 | RFCAAAA |
			| | | |
			| Full | 2 | RFCAAAA |
			| | | |
			| Reserved | 63 | RFCAAAA |
			| | | |
			| Reserved | 255 | RFCAAAA |
			+--------------+-------+---------------+
	7. IANA Considerations		Table 2: EKT Messages Types
	No IANA actions are required.		Note to RFC Editor: Please replace RFCAAAA with the RFC number for
			this specification.
	8. Acknowledgements		New entries to this table can be added via "Specification Required"
			as defined in [RFC5226]. When requesting a new value, the requestor
			needs to indicate if it is mandatory to understand or not. If it is
			mandatory to understand, IANA needs to allocate a value less than 64,
			if it is not mandatory to understand, a value greater than or equal
			to 64 needs to be allocated. IANA SHOULD prefer allocation of even
			values over odd ones until the even code points are consumed to avoid
			conflicts with pre standard versions of EKT that have been deployed.
	Thanks to David Benham, Eddy Lem, Felix Wyss, Jonathan Lennox, Kai		5.2. EKT Ciphers
	Fischer, Lakshminath Dondeti, Magnus Westerlund, Michael Peck,
	Nermeen Ismail, Paul Jones, Rob Raymond, and Yi Cheng for fruitful		IANA is requested to create a new registry for "EKT Ciphers". The
	discussions, comments, and contributions to this document.		initial values in this registry are:
			+----------+-------+---------------+
			| Name | Value | Specification |
			+----------+-------+---------------+
			| AESKW128 | 1 | RFCAAAA |
			| | | |
			| AESKW256 | 3 | RFCAAAA |
			| | | |
			| Reserved | 255 | RFCAAAA |
			+----------+-------+---------------+
			Table 3: EKT Cipher Types
			Note to RFC Editor: Please replace RFCAAAA with the RFC number for
			this specification.
			New entries to this table can be added via "Specification Required"
			as defined in [RFC5226]. The expert SHOULD ensure the specification
			defines the values for L and T as required in Section 2.3 of RFCAAA.
			Allocated values MUST be in the range of 1 to 254.
			5.3. TLS Extensions
			IANA is requested to add "srtp_ekt_key_transport" as an new extension
			name to the "ExtensionType Values" table of the "Transport Layer
			Security (TLS) Extensions" registry with a reference to this
			specification and allocate a value of TBD to for this. Note to RFC
			Editor: TBD will be allocated by IANA.
			Considerations for this type of extension are described in Section 5
			of [RFC4366] and requires "IETF Consensus".
			5.4. TLS Content Type
			IANA is requested to add "srtp_ekt_message" as an new descriptions
			name to the "TLS ContentType Registry" table of the "Transport Layer
			Security (TLS) Extensions" registry with a reference to this
			specification, a DTLS-OK value of "Y", and allocate a value of TBD to
			for this content type. Note to RFC Editor: TBD will be allocated by
			IANA.
			This registry was defined in Section 12 of [RFC5246] and requires
			"Standards Action".
			6. Acknowledgements
			Thank you to Russ Housley provided detailed review and significant
			help with crafting text for this document. Thanks to David Benham,
			Eddy Lem, Felix Wyss, Jonathan Lennox, Kai Fischer, Lakshminath
			Dondeti, Magnus Westerlund, Michael Peck, Nermeen Ismail, Paul Jones,
			Rob Raymond, and Yi Cheng for fruitful discussions, comments, and
			contributions to this document.
	This draft is a cut down version of draft-ietf-avtcore-srtp-ekt-03		This draft is a cut down version of draft-ietf-avtcore-srtp-ekt-03
	and most of the text here came from that draft.		and much of the text here came from that draft.
	9. References		7. References
	9.1. Normative References		7.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>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<http://www.rfc-editor.org/info/rfc4086>.		<http://www.rfc-editor.org/info/rfc4086>.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			DOI 10.17487/RFC5226, May 2008,
			<http://www.rfc-editor.org/info/rfc5226>.
			[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", STD 68, RFC 5234,
			DOI 10.17487/RFC5234, January 2008,
			<http://www.rfc-editor.org/info/rfc5234>.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246,
			DOI 10.17487/RFC5246, August 2008,
			<http://www.rfc-editor.org/info/rfc5246>.
	[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard		[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
	(AES) Key Wrap with Padding Algorithm", RFC 5649, DOI		(AES) Key Wrap with Padding Algorithm", RFC 5649,
	10.17487/RFC5649, September 2009,		DOI 10.17487/RFC5649, September 2009,
	<http://www.rfc-editor.org/info/rfc5649>.		<http://www.rfc-editor.org/info/rfc5649>.
	[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>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <http://www.rfc-editor.org/info/rfc6347>.
	9.2. Informative References		7.2. Informative References
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264, DOI		with Session Description Protocol (SDP)", RFC 3264,
	10.17487/RFC3264, June 2002,		DOI 10.17487/RFC3264, June 2002,
	<http://www.rfc-editor.org/info/rfc3264>.		<http://www.rfc-editor.org/info/rfc3264>.
			[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
			and T. Wright, "Transport Layer Security (TLS)
			Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
			<http://www.rfc-editor.org/info/rfc4366>.
	Authors' Addresses		Authors' Addresses
			Cullen Jennings
			Cisco Systems
			Calgary, AB
			Canada
			Email: fluffy@iii.ca
	John Mattsson (editor)		John Mattsson (editor)
	Ericsson AB		Ericsson AB
	SE-164 80 Stockholm		SE-164 80 Stockholm
	Sweden		Sweden
	Phone: +46 10 71 43 501		Phone: +46 10 71 43 501
	Email: john.mattsson@ericsson.com		Email: john.mattsson@ericsson.com
	David A. McGrew		David A. McGrew
	Cisco Systems		Cisco Systems
	510 McCarthy Blvd.		510 McCarthy Blvd.
	Milpitas, CA 95035		Milpitas, CA 95035
	US		US
	Phone: (408) 525 8651		Phone: (408) 525 8651
	Email: mcgrew@cisco.com		Email: mcgrew@cisco.com
	URI: http://www.mindspring.com/~dmcgrew/dam.htm		URI: http://www.mindspring.com/~dmcgrew/dam.htm
	Dan Wing		Dan Wing
	Cisco Systems		Cisco Systems
	510 McCarthy Blvd.		510 McCarthy Blvd.
	Milpitas, CA 95035		Milpitas, CA 95035
	US		US
	Phone: (408) 853 4197		Phone: (408) 853 4197
	Email: dwing@cisco.com		Email: dwing@cisco.com
	Flemming Andreason		Flemming Andreason
	skipping to change at page 18, line 20 ¶		skipping to change at line 927 ¶
	Phone: (408) 853 4197		Phone: (408) 853 4197
	Email: dwing@cisco.com		Email: dwing@cisco.com
	Flemming Andreason		Flemming Andreason
	Cisco Systems		Cisco Systems
	499 Thornall Street		499 Thornall Street
	Edison, NJ 08837		Edison, NJ 08837
	US		US
	Email: fandreas@cisco.com		Email: fandreas@cisco.com
	Cullen Jennings
	Cisco Systems
	Calgary, AB
	Canada
	Email: fluffy@iii.ca
End of changes. 117 change blocks.
	379 lines changed or deleted		534 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/