draft-ietf-perc-srtp-ekt-diet-02.txt		draft-ietf-perc-srtp-ekt-diet-03.txt
	PERC Working Group C. Jennings		PERC Working Group C. Jennings
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Mattsson, Ed.		Intended status: Standards Track J. Mattsson, Ed.
	Expires: May 4, 2017 Ericsson		Expires: September 14, 2017 Ericsson
	D. McGrew		D. McGrew
	D. Wing		D. Wing
	F. Andreasen		F. Andreasen
	Cisco		Cisco
	October 31, 2016		March 13, 2017
	Encrypted Key Transport for Secure RTP		Encrypted Key Transport for Secure RTP
	draft-ietf-perc-srtp-ekt-diet-02		draft-ietf-perc-srtp-ekt-diet-03
	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 for decentralized conferences by		SRTP. This facility enables SRTP for decentralized conferences by
	distributing a common key to all of the conference endpoints.		distributing a common key to all of the conference endpoints.
	Status of This Memo		Status of This Memo
	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 19 ¶		skipping to change at page 2, line 19 ¶
	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 . . . . . . . . . . . . . . . . . 8		2.2.2. Inbound Processing . . . . . . . . . . . . . . . . . 8
	2.3. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.3. Implementation Notes . . . . . . . . . . . . . . . . . . 9
	2.3.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 10		2.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 10		2.4.1. Ciphers . . . . . . . . . . . . . . . . . . . . . . . 10
	2.4. Synchronizing Operation . . . . . . . . . . . . . . . . . 10		2.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 11
	2.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11		2.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 11
	2.6. Timing and Reliability Consideration . . . . . . . . . . 11		2.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
			2.7. Timing and Reliability Consideration . . . . . . . . . . 11
	3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 12		3. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 12
	3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 12		3.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 12
	3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 12		3.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 13
	3.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 15		3.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 15
	3.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 15		3.4. Sending the DTLS EKT_Key Reliably . . . . . . . . . . . . 15
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 15		4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	5.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 17		5.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 17
	5.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 17		5.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 18
	5.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 18		5.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 18
	5.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 18		5.4. TLS Content Type . . . . . . . . . . . . . . . . . . . . 18
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Normative References . . . . . . . . . . . . . . . . . . 19		7.1. Normative References . . . . . . . . . . . . . . . . . . 19
	7.2. Informative References . . . . . . . . . . . . . . . . . 20		7.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Real-time Transport Protocol (RTP) is designed to allow decentralized		Real-time Transport Protocol (RTP) is designed to allow decentralized
	groups with minimal control to establish sessions, such as for		groups with minimal control to establish sessions, such as for
	multimedia conferences. Unfortunately, Secure RTP ( SRTP [RFC3711])		multimedia conferences. Unfortunately, Secure RTP ( SRTP [RFC3711])
	cannot be used in many minimal-control scenarios, because it requires		cannot be used in many minimal-control scenarios, because it requires
	that synchronization source (SSRC) values and other data be		that synchronization source (SSRC) values and other data be
	coordinated among all of the participants in a session. For example,		coordinated among all of the participants in a session. For example,
	if a participant joins a session that is already in progress, that		if a participant joins a session that is already in progress, that
	participant needs to be told the SRTP keys along with the SSRC, roll		participant needs to be told the SRTP keys along with the SSRC,
	over counter (ROC) and other details of the other SRTP sources.		rollover 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 the central		conjunction with a signaling system that can provide the central
	control needed by SRTP. However, there are several cases in which		control needed by SRTP. However, there are several cases in 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
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	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 corresponding to the		endpoint. In order to convey the ciphertext corresponding to the
	SRTP master key, and other additional information, an additional EKT		SRTP master key, and other additional information, an additional EKT
	field is added to SRTP packets. When added to SRTP, the EKT field		field is added to SRTP packets. The EKT field appears at the end of
	appears at the end of the SRTP packet, after the authentication tag		the SRTP packet. The EKT field appears after the optional
	(if that tag is present), or after the ciphertext of the encrypted		authentication tag if one is present, otherwise the EKT field appears
	portion of the packet otherwise.		after the ciphertext portion of the packet.
	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. Senders MUST not
			include MKI when using EKT. Receivers SHOULD simply ignore any MKI
			field received if EKT is in use.
	2.1. EKT Field Formats		2.1. EKT Field Formats
	The EKT Field uses the format defined below for the FullEKTField and		The EKT Field uses the format defined below for the FullEKTField and
	ShortEKTField.		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	: :		: :
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 43 ¶
	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
	The following shows the syntax of the EKTField expressed in ABNF		The following shows the syntax of the EKTField expressed in ABNF
	[RFC5234]. The EKTField is added to the end of an SRTP or SRTCP		[RFC5234]. The EKTField is added to the end of an SRTP or SRTCP
	packet. The EKTCiphertext is computed by encrypting the EKTPlaintext		packet. The EKTPlaintext is the concatenation of
	using the EKTKey. Future extensions to the EKTField MUST conform to		SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The
	the syntax of ExtensionEKTField.		EKTCiphertext is computed by encrypting the EKTPlaintext using the
			EKTKey. Future extensions to the EKTField MUST conform to the syntax
			of ExtensionEKTField.
	BYTE = %x00-FF		BYTE = %x00-FF
	EKTMsgTypeFull = %x02		EKTMsgTypeFull = %x02
	EKTMsgTypeShort = %x00		EKTMsgTypeShort = %x00
	EKTMsgTypeExtension = %x03-FF		EKTMsgTypeExtension = %x03-FF
	EKTMsgLength = 2BYTE;		EKTMsgLength = 2BYTE;
	SRTPMasterKeyLength = BYTE		SRTPMasterKeyLength = BYTE
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 42 ¶
	Figure 3: EKTField Syntax		Figure 3: EKTField Syntax
	These fields and data elements are defined as follows:		These fields and data elements are defined as follows:
	EKTPlaintext: 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, and the ROC.		SRTP Master Key, the SSRC, and the ROC.
	EKTCiphertext: 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.4. This field is included in
	SRTP packets when EKT is in use.		SRTP packets when EKT is in use. The length of EKTCiphertext can
			be larger than the length of the EKTPlaintext that was encrypted.
	SRTPMasterKey: On the sender side, the SRTP Master Key associated		SRTPMasterKey: On the sender side, the SRTP Master Key associated
	with the indicated SSRC.		with the indicated SSRC.
	SRTPMasterKeyLength: The length of the SRTPMasterKey. This depends		SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This
	on the cipher suite negotiated for SRTP using [RFC3264] SDP Offer/		depends on the cipher suite negotiated for SRTP using [RFC3264]
	Answer for the SRTP.		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.
	Security Parameter Index (SPI): This field indicates the appropriate		Security Parameter Index (SPI): This field indicates the appropriate
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 30 ¶
	* 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. The Master Salt is communicated separately,		with this EKT Key. The Master Salt is communicated separately,
	via signaling, typically along with the EKTKey.		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.
	Each distinct EKT parameter set that is used MUST be associated		Each distinct EKT parameter set that is used MUST be associated
	with a distinct SPI value to avoid ambiguity.		with a distinct SPI value to avoid ambiguity.
	EKTMsgLength All EKT message other that ShortEKTField must have a		EKTMsgLength: All EKT message other that ShortEKTField have a length
	length as second from the last element. This is the length in		as second from the last element. This is the length in octets of
	octets of either the FullEKTField/ExtensionEKTField including this		either the FullEKTField/ExtensionEKTField including this length
	length field and the following message type.		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
	EKTField. This MUST be 2 in the FullEKTField format and 0 in		EKTField. This MUST be 2 in the FullEKTField format and 0 in
	ShortEKTField format. Values less than 64 are mandatory to		ShortEKTField format. Values less than 64 are mandatory to
	understand and the whole EKTField SHOULD be discarded if it		understand while other values are optional to understand. A
	contains message type value that is less than 64 and is not		receiver SHOULD discard the whole EKTField if it contains any
	implemented.		message type value that is less than 64 and that is not
			understood. Message type values that are 64 or greater but not
			implemented or understood can simply be ignored.
	2.2. Packet Processing and State Machine		2.2. Packet Processing and State Machine
	At any given time, each SRTP/SRTCP source has associated with it a		At any given time, each SRTP/SRTCP source has associated with it a
	single EKT parameter set. This parameter set is used to process all		single EKT parameter set. This parameter set is used to process all
	outbound packets, and is called the outbound parameter set for that		outbound packets, and is called the outbound parameter set for that
	SSRC. There may be other EKT parameter sets that are used by other		SSRC. There may be other EKT parameter sets that are used by other
	SRTP/SRTCP sources in the same session, including other SRTP/SRTCP		SRTP/SRTCP sources in the same session, including other SRTP/SRTCP
	sources on the same endpoint (e.g., one endpoint with voice and video		sources on the same endpoint (e.g., one endpoint with voice and video
	might have two EKT parameter sets, or there might be multiple video		might have two EKT parameter sets, or there might be multiple video
	sources on an endpoint each with their own EKT parameter set). All		sources on an endpoint each with their own EKT parameter set). 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.
	Either the FullEKTField or ShortEKTField is appended at the tail end		Either the FullEKTField or ShortEKTField is appended at the tail end
	of all SRTP packets.		of all SRTP packets. The decision on which to send is specified in
			Section 2.7.
	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.7 which describes when to send an SRTP packet with a
	FullEKTField. If a FullEKTField is not being sent, then a		FullEKTField. If a FullEKTField is not being sent, then a
	ShortEKTField needs to be sent so the receiver can correctly		ShortEKTField is sent so the receiver can correctly determine how to
	determine how to process the packet.		process the packet.
	When an SRTP packet is to be sent with a FullEKTField, the EKTField		When an SRTP packet is sent with a FullEKTField, the EKTField for
	for that packet is created as follows, or uses an equivalent set of		that packet is created as follows, or uses an equivalent set of
	steps. The creation of the EKTField MUST precede the normal SRTP		steps. The creation of the EKTField MUST precede the normal SRTP
	packet processing.		packet processing.
	1. The Security Parameter Index (SPI) field is set to the value of		1. The Security Parameter Index (SPI) field is set to the value of
	the 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 EKTPlaintext 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 EKTCiphertext field is set to the ciphertext created by		3. The EKTCiphertext field is set to the ciphertext created by
	encrypting the EKTPlaintext with the EKT cipher, using the EKTKey		encrypting the EKTPlaintext with the EKT cipher, using the EKTKey
	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.4.
	4. Then the FullEKTField is formed using the EKTCiphertext and the		4. Then the FullEKTField is formed using the EKTCiphertext and the
	SPI associated with the EKTKey used above. Also appended are the		SPI associated with the EKTKey used above. Also appended are the
	Length and EKTMEsgTypeFull elements.		Length and Message Type using the FullEKTField format.
	Note: the value of the EKT Ciphertext field is identical in		Note: the value of the EKTCiphertext field is identical in
	successive packets protected by the same EKTKey and SRTP		successive packets protected by the same EKTKey and SRTP
	master key. This value MAY be cached by an SRTP sender to		master key. This value MAY be cached by an SRTP sender to
	minimize computational effort.		minimize computational effort.
	The computed value of the FullEKTField is written into the		The computed value of the FullEKTField is written into the
	packet.		packet.
	When a packet is sent with the Short EKT Field, the ShortEKFField is		When a packet is sent with the Short EKT Field, the ShortEKFField is
	simply appended to the packet.		simply appended to the packet.
	2.2.2. Inbound Processing		2.2.2. Inbound Processing
	When receiving a packet on a RTP stream where EKT was negotiated, the		When receiving a packet on a RTP stream, the following steps are
	following steps are applied for each received packet.		applied for each received packet.
	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 ShortEKTField, the		use. When an SRTP or SRTCP packet contains a ShortEKTField, the
	ShortEKTField is removed from the packet then normal SRTP or		ShortEKTField is removed from the packet then normal SRTP or
	SRTCP processing occurs. If the packet contains a FullEKTField,		SRTCP processing occurs. If the packet contains a FullEKTField,
	then processing continues as described below.		then processing continues as described below. The reason for
			using the last byte of the packet to indicate the type is that
			the length of the SRTP or SRTCP part is not known until the
			decryption has occurred. At this point in the processing, there
			is no easy way to know where the EKT field would start. However,
			the whole UDP packet has been received so instead of the starting
			at the front of the packet, the parsing works backwards off the
			end of the packet and thus the type is put at the very end of the
			packet.
	2. The Security Parameter Index (SPI) field is used to find which		2. The Security Parameter Index (SPI) field is used to find which
	EKT parameter set to be used when processing the packet. If		EKT parameter set to be used when processing the packet. If
	there is no matching SPI, then the verification function MUST		there is no matching SPI, then the verification function MUST
	return an indication of authentication failure, and the steps		return an indication of authentication failure, and the steps
	described below are not performed. The EKT parameter set		described below are not performed. The EKT parameter set
	contains the EKTKey, EKTCipher, and SRTP Master Salt.		contains the EKTKey, EKTCipher, and SRTP Master Salt.
	3. The EKTCiphertext 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 EKTKey and EKTCipher found		as described in Section 2.4, using the EKTKey and EKTCipher found
	in the previous step. If the EKT decryption operation returns an		in the previous step. If the EKT decryption operation returns an
	authentication failure, then the packet processing stops.		authentication failure, then the packet processing stops.
	4. The resulting EKTPlaintext is parsed as described in Section 2.1,		4. The resulting EKTPlaintext is parsed as described in Section 2.1,
	to recover the SRTP Master Key, SSRC, and ROC fields. The Master		to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP
	Salt that is associated with the EKTKey is also retrieved. If		Master Salt that is associated with the EKTKey is also retrieved.
	the value of the srtp_master_salt sent as part of the EKTkey is		If the value of the srtp_master_salt sent as part of the EKTkey
	longer than needed by SRTP, then it is truncated by taking the		is longer than needed by SRTP, then it is truncated by taking the
	first N bytes from the srtp_master_salt field.		first N bytes from the srtp_master_salt field.
	5. The SRTP Master Key, ROC, and SRTP Master Salt from the previous		5. If the SSRC in the EKTPlaintext does not match the SSRC of the
			SRTP packet, then all the information from this EKTPlaintext MUST
			be discarded and the following steps in this list are not done.
			6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous
	step are saved in a map indexed by the SSRC found in the		step are saved in a map indexed by the SSRC found in the
	EKTPlaintext and can be used for any future crypto operations on		EKTPlaintext and can be used for any future crypto operations on
	the inbound packets with that SSRC. Outbound packets SHOULD		the inbound packets with that SSRC. Outbound packets SHOULD
	continue to use the old SRTP Master Key for 250 ms after sending		continue to use the old SRTP Master Key for 250 ms after sending
	any new key. This gives all the receivers in the system time to		any new key. This gives all the receivers in the system time to
	get the new key before they start receiving media encrypted with		get the new key before they start receiving media encrypted with
	the new key.		the new key.
	6. At this point, EKT processing has successfully completed, and the		7. 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.
	2.2.2.1. Implementation Notes for Inbound Processing		2.3. Implementation Notes
	The value of the EKTCiphertext field is identical in successive		The value of the EKTCiphertext field is identical in successive
	packets protected by the same EKT parameter set and the same SRTP		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		master key, and ROC. This ciphertext value MAY be cached by an SRTP
	receiver to minimize computational effort by noting when the SRTP		receiver to minimize computational effort by noting when the SRTP
	master key is unchanged and avoiding repeating the above steps.		master key is unchanged and avoiding repeating the above steps.
	The receiver may want to have a sliding window to retain old SRTP		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		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		that out of order packets can be processed as well as packets sent
	during the time keys are changing.		during the time keys are changing.
	2.3. Ciphers		When receiving a new EKTKey, implementations need to use the ekt_ttl
			to create a time after which this key cannot be used and they also
			need to create a counter that keeps track of how many times the keys
			has been used to encrypt data to ensure it does not exceed the T
			value for that cipher. If either of these limits are exceeded, the
			key can no longer be used for encryption. At this point
			implementation need to either use the call signaling to renegotiation
			a new session or need to terminate the existing session. Terminating
			the session is a reasonable implementation choice because these
			limits should not be exceeded except under an attack or error
			condition.
			2.4. Ciphers
	EKT uses an authenticated cipher to encrypt and authenticate the		EKT uses an authenticated cipher to encrypt and authenticate the
	EKTPlaintext. We first specify the interface to the cipher, in order		EKTPlaintext. This specification defines the interface to the
	to abstract the interface away from the details of that function. We		cipher, in order to abstract the interface away from the details of
	then define the cipher that is used in EKT by default. The default		that function. This specification also defines the default cipher
	cipher described in Section 2.3.1 MUST be implemented, but another		that is used in EKT. The default cipher described in Section 2.4.1
	cipher that conforms to this interface MAY be used, in which case its		MUST be implemented, but another cipher that conforms to this
	use MUST be coordinated by external means (e.g., key management).		interface MAY be used.
	An EKTCipher 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 may be larger than M. The decryption function D(K,		N bytes, where N may be larger than M. The decryption function D(K,
	C) 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 at least		The decryption function returns a plaintext value P that is M bytes
	M bytes long, or returns an indication that the decryption operation		long, or returns an indication that the decryption operation failed
	failed because the ciphertext was invalid (i.e. it was not generated		because the ciphertext was invalid (i.e. it was not generated by the
	by the encryption of plaintext with the key K).		encryption of plaintext with the key K).
	These functions have the property that D(K, E(K, P)) = ( P		These functions have the property that D(K, E(K, P)) = P for all
	concatenated with optional padding) for all values of K and P. Each		values of K and P. Each cipher also has a limit T on the number of
	cipher also has a limit T on the number of times that it can be used		times that it can be used with any fixed key value. The EKTKey MUST
	with any fixed key value. The EKTKey MUST NOT be used more that T		NOT be used for encryption more that T times. Note that if the same
	times.		FullEKTField is retransmitted 3 times, that only counts as 1
			encryption.
	Security requirements for EKT ciphers are discussed in Section 4.		Security requirements for EKT ciphers are discussed in Section 4.
	2.3.1. Ciphers		2.4.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 + (M mod 8) + 8 octets. It can be used with key		a length of N = M + (M mod 8) + 8 octets. It can be used with key
	sizes of L = 16, and L = 32 octets, and its use with those key sizes		sizes of L = 16, and L = 32 octets, and its use with those key sizes
	is indicated as AESKW128, or AESKW256, respectively. The key size		is indicated as AESKW128, or AESKW256, respectively. The key size
	determines the length of the AES key used by the Key Wrap algorithm.		determines the length of the AES key used by the Key Wrap algorithm.
	With this cipher, T=2^48.		With this cipher, T=2^48.
	skipping to change at page 10, line 29 ¶		skipping to change at page 11, line 8 ¶
	| AESKW128 | 16 | 2^48 |		| AESKW128 | 16 | 2^48 |
	| | | |		| | | |
	| AESKW256 | 32 | 2^48 |		| AESKW256 | 32 | 2^48 |
	+----------+----+------+		+----------+----+------+
	Table 1: EKT Ciphers		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],
	AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented.		AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented.
	2.3.2. Defining New EKT Ciphers		2.4.2. Defining New EKT Ciphers
	Other specifications may extend this document by defining other		Other specifications may extend this document by defining other
	EKTCiphers as described in Section 5. This section defines how those		EKTCiphers as described in Section 5. This section defines how those
	ciphers interact with this specification.		ciphers interact with this specification.
	An EKTCipher determines how the EKTCiphertext 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, and T MUST be defined by		an input. The values of the parameters L, and T MUST be defined by
	each EKTCipher.		each EKTCipher. The cipher MUST provide integrity protection.
	2.4. Synchronizing Operation		2.5. Synchronizing Operation
	If a source has its EKTKey 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 FullEKTField. This ensures that if key management thought the		new FullEKTField. This ensures that if key management thought the
	EKTKey needs changing (due to a participant leaving or joining) and		EKTKey needs changing (due to a participant leaving or joining) and
	communicated that to a source, the source will also change its SRTP		communicated that to a source, the source will also change its SRTP
	master key, so that traffic can be decrypted only by those who know		master key, so that traffic can be decrypted only by those who know
	the current EKTKey.		the current EKTKey.
	2.5. Transport		2.6. 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.7. Timing and Reliability Consideration
	A system using EKT learns the SRTP master keys distributed with		A system using EKT learns the SRTP master keys distributed with
	FullEKTFields sent 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 packet, provided the SRTP		receiver can immediately decrypt an SRTP packet, provided the SRTP
	packet 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
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 19 ¶
	This document defines a new TLS negotiated extension called		This document defines a new TLS negotiated extension called
	"srtp_ekt_key_transport"and a new TLS content type called EKTMessage.		"srtp_ekt_key_transport"and a new TLS content type called EKTMessage.
	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 {
	reserved(0),		reserved(0),
	aeskw_128(1),		aeskw_128(1),
	aeskw_256(3),		aeskw_256(2),
	} EKTCipherType;		} EKTCipherType;
	struct {		struct {
	EKTCipherType ekt_ciphers<0..254>;		EKTCipherType ekt_ciphers<1..255>;
	} SupportedEKTCiphers;		} SupportedEKTCiphers;
	struct {		struct {
	EKTCipherType ekt_cipher;		EKTCipherType ekt_cipher;
	uint ekt_key_value<1..256>;		uint ekt_key_value<1..256>;
	uint srtp_master_salt<1..256>;		uint srtp_master_salt<1..256>;
	uint16 ekt_spi;		uint16 ekt_spi;
	uint24 ekt_ttl;		uint24 ekt_ttl;
	} EKTkey;		} EKTkey;
	skipping to change at page 13, line 48 ¶		skipping to change at page 14, line 10 ¶
	} message;		} message;
	} EKTMessage;		} EKTMessage;
	Figure 4: Additional TLS Data Structures		Figure 4: Additional TLS Data Structures
	If a DTLS client includes "srtp_ekt_key_transport" in its		If a DTLS client includes "srtp_ekt_key_transport" in its
	ClientHello, then a DTLS server that supports this extensions will		ClientHello, then a DTLS server that supports this extensions will
	includes "srtp_ekt_key_transport" in its ServerHello message. If a		includes "srtp_ekt_key_transport" in its ServerHello message. If a
	DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but		DTLS client includes "srtp_ekt_key_transport" in its ClientHello, but
	does not receive "srtp_ekt_key_transport" in the ServerHello, the		does not receive "srtp_ekt_key_transport" in the ServerHello, the
	DTLS client MUST NOT send DTLS EKTMessage messages.		DTLS client MUST NOT send DTLS EKTMessage messages. Also, the
			"srtp_ekt_key_transport" in the ServerHello MUST select one and only
			one EKTCipherType from the list provided by the client in the
			"srtp_ekt_key_transport" in the ClientHello.
	When a DTLS client sends the "srtp_ekt_key_transport" in its		When a DTLS client sends the "srtp_ekt_key_transport" in its
	ClientHello message, it MUST include the SupportedEKTCiphers as the		ClientHello message, it MUST include the SupportedEKTCiphers as the
	extension_data for the extension, listing the EKTCipherTypes the		extension_data for the extension, listing the EKTCipherTypes the
	client is willing to use in preference order, with the most preferred		client is willing to use in preference order, with the most preferred
	version first. When the server responds in the		version first. When the server responds in the
	"srtp_ekt_key_transport" in its ServerHello message, it must include		"srtp_ekt_key_transport" in its ServerHello message, it MUST include
	a SupportedEKTCiphers list that selects a single EKTCipherType to use		a SupportedEKTCiphers list that selects a single EKTCipherType to use
	(selected from the list provided by the client) or it returns an		(selected from the list provided by the client) or it returns an
	empty list to indicate there is no matching EKTCipherType in the		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		clients list that the server is also willing to use. The value to be
	used in the EKTCipherType for future extensions that define new		used in the EKTCipherType for future extensions that define new
	ciphers is the value from the "EKT Ciphers Type" IANA registry		ciphers is the value from the "EKT Ciphers Type" IANA registry
	defined in Section 5.2.		defined in Section 5.2.
	The figure above defines the contents for a new TLS content type		The figure above defines the contents for a new TLS content type
	called EKTMessage which is registered in Section 5.4. The EKTMessage		called EKTMessage which is registered in Section 5.4. The EKTMessage
	skipping to change at page 16, line 13 ¶		skipping to change at page 16, line 13 ¶
	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		SRTP master keys MUST be randomly generated, and [RFC4086] offers
	some guidance about random number generation. SRTP master keys MUST		some guidance about random number generation. SRTP master keys MUST
	NOT be re-used for any other purpose, and SRTP master keys MUST NOT		NOT be re-used for any other purpose, and SRTP master keys MUST NOT
	be derived from other SRTP master keys.		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 FullEKTField, 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 EKTPlaintext ensures that an attacker		The presence of the SSRC in the EKTPlaintext ensures that an attacker
	cannot substitute an EKTCiphertext from one SRTP stream into another		cannot substitute an EKTCiphertext from one SRTP stream into another
	SRTP stream.		SRTP stream.
	An attacker who tampers with the bits in FullEKTField can prevent the		An attacker who tampers with the bits in FullEKTField can prevent the
	intended receiver of that packet from being able to decrypt it. This		intended receiver of that packet from being able to decrypt it. This
	is a minor denial of service vulnerability.		is a minor denial of service vulnerability. Similarly the attacker
			could take an old FullEKTField from the same session and attach it to
			the packet. The FullEKTField would correctly decode and pass
			integrity but the key extracted from the FullEKTField , when used to
			decrypt the SRTP payload, would be wrong and the SRTP integrity check
			would fail. Note that the FullEKTField only changes the decryption
			key and does not change the encryption key. None of these are
			considered significant attacks as any attacker that can modify the
			packets in transit and cause the integrity check to fail.
	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. In some cases, caching the		detect an authentication failure. In some cases, caching the
	previous values of the Ciphertext as described in Section 2.2.2.1		previous values of the Ciphertext as described in Section 2.3 helps
	helps mitigate this issue.		mitigate this issue.
	Each EKT cipher specifies a value T that is the maximum number of		Each EKT cipher specifies a value T that is the maximum number of
	times a given key can be used. An endpoint MUST NOT send more than T		times a given key can be used. An endpoint MUST NOT encrypt more
	Full EKT Field using the same EKTKey. In addition, the EKTKey MUST		than T different Full EKT Field using the same EKTKey. In addition,
	NOT be used beyond the lifetime provided by the TTL described in		the EKTKey MUST NOT be used beyond the lifetime provided by the TTL
	Section 3.2.		described in Section 3.2.
	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 and at least as strong		MUST be at least as strong as the SRTP cipher and at least as strong
	as the DTLS-SRTP ciphers.		as the DTLS-SRTP ciphers.
	Part of the EKTPlaintext 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.
	In some systems, when a member of a conference leaves the		In some systems, when a member of a conference leaves the
	conferences, the conferences is rekeyed so that member no longer has		conferences, the conferences is rekeyed so that member no longer has
	skipping to change at page 17, line 17 ¶		skipping to change at page 17, line 25 ¶
	the key. When changing to a new EKTKey, it is possible that the		the key. When changing to a new EKTKey, it is possible that the
	attacker could block the EKTKey message getting to a particular		attacker could block the EKTKey message getting to a particular
	endpoint and that endpoint would keep sending media encrypted using		endpoint and that endpoint would keep sending media encrypted using
	the old key. To mitigate that risk, the lifetime of the EKTKey		the old key. To mitigate that risk, the lifetime of the EKTKey
	SHOULD be limited using the ekt_ttl.		SHOULD be limited using the ekt_ttl.
	5. IANA Considerations		5. IANA Considerations
	5.1. EKT Message Types		5.1. EKT Message Types
	IANA is requested to create a new registry for "EKT Messages Types".		IANA is requested to create a new table for "EKT Messages Types" in
	The initial values in this registry are:		the "Real-Time Transport Protocol (RTP) Parameters" registry. The
			initial values in this registry are:
	+--------------+-------+---------------+		+--------------+-------+---------------+
	| Message Type | Value | Specification |		| Message Type | Value | Specification |
	+--------------+-------+---------------+		+--------------+-------+---------------+
	| Short | 0 | RFCAAAA |		| Short | 0 | RFCAAAA |
	| | | |		| | | |
	| Full | 2 | RFCAAAA |		| Full | 2 | RFCAAAA |
	| | | |		| | | |
	| Reserved | 63 | RFCAAAA |		| Reserved | 63 | RFCAAAA |
	| | | |		| | | |
	skipping to change at page 17, line 46 ¶		skipping to change at page 18, line 7 ¶
	New entries to this table can be added via "Specification Required"		New entries to this table can be added via "Specification Required"
	as defined in [RFC5226]. When requesting a new value, the requestor		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		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,		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		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		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		values over odd ones until the even code points are consumed to avoid
	conflicts with pre standard versions of EKT that have been deployed.		conflicts with pre standard versions of EKT that have been deployed.
			All new EKT messages MUST be defined to have a length as second from
			the last element.
	5.2. EKT Ciphers		5.2. EKT Ciphers
	IANA is requested to create a new registry for "EKT Ciphers". The		IANA is requested to create a new table for "EKT Ciphers" in the
			"Real-Time Transport Protocol (RTP) Parameters" registry. The
	initial values in this registry are:		initial values in this registry are:
	+----------+-------+---------------+		+----------+-------+---------------+
	| Name | Value | Specification |		| Name | Value | Specification |
	+----------+-------+---------------+		+----------+-------+---------------+
	| AESKW128 | 1 | RFCAAAA |		| AESKW128 | 1 | RFCAAAA |
	| | | |		| | | |
	| AESKW256 | 3 | RFCAAAA |		| AESKW256 | 2 | RFCAAAA |
	| | | |		| | | |
	| Reserved | 255 | RFCAAAA |		| Reserved | 255 | RFCAAAA |
	+----------+-------+---------------+		+----------+-------+---------------+
	Table 3: EKT Cipher Types		Table 3: EKT Cipher Types
	Note to RFC Editor: Please replace RFCAAAA with the RFC number for		Note to RFC Editor: Please replace RFCAAAA with the RFC number for
	this specification.		this specification.
	New entries to this table can be added via "Specification Required"		New entries to this table can be added via "Specification Required"
	as defined in [RFC5226]. The expert SHOULD ensure the specification		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.		defines the values for L and T as required in Section 2.4 of RFCAAA.
	Allocated values MUST be in the range of 1 to 254.		Allocated values MUST be in the range of 1 to 254.
	5.3. TLS Extensions		5.3. TLS Extensions
	IANA is requested to add "srtp_ekt_key_transport" as an new extension		IANA is requested to add "srtp_ekt_key_transport" as an new extension
	name to the "ExtensionType Values" table of the "Transport Layer		name to the "ExtensionType Values" table of the "Transport Layer
	Security (TLS) Extensions" registry with a reference to this		Security (TLS) Extensions" registry with a reference to this
	specification and allocate a value of TBD to for this. Note to RFC		specification and allocate a value of TBD to for this. Note to RFC
	Editor: TBD will be allocated by IANA.		Editor: TBD will be allocated by IANA.
	skipping to change at page 18, line 52 ¶		skipping to change at page 19, line 15 ¶
	for this content type. Note to RFC Editor: TBD will be allocated by		for this content type. Note to RFC Editor: TBD will be allocated by
	IANA.		IANA.
	This registry was defined in Section 12 of [RFC5246] and requires		This registry was defined in Section 12 of [RFC5246] and requires
	"Standards Action".		"Standards Action".
	6. Acknowledgements		6. Acknowledgements
	Thank you to Russ Housley provided detailed review and significant		Thank you to Russ Housley provided detailed review and significant
	help with crafting text for this document. Thanks to David Benham,		help with crafting text for this document. Thanks to David Benham,
	Eddy Lem, Felix Wyss, Jonathan Lennox, Kai Fischer, Lakshminath		Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul
	Dondeti, Magnus Westerlund, Michael Peck, Nermeen Ismail, Paul Jones,		Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean
	Rob Raymond, and Yi Cheng for fruitful discussions, comments, and		Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions,
	contributions to this document.		comments, and contributions to this document.
	This draft is a cut down version of draft-ietf-avtcore-srtp-ekt-03
	and much of the text here came from that draft.
	7. References		7. References
	7.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,		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>.
	[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		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
	DOI 10.17487/RFC5234, January 2008,		RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<http://www.rfc-editor.org/info/rfc5234>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
	DOI 10.17487/RFC5246, August 2008,		RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<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,		(AES) Key Wrap with Padding Algorithm", RFC 5649, DOI
	DOI 10.17487/RFC5649, September 2009,		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,		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>.
	[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>.
	7.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,		with Session Description Protocol (SDP)", RFC 3264, DOI
	DOI 10.17487/RFC3264, June 2002,		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.,		[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
	and T. Wright, "Transport Layer Security (TLS)		and T. Wright, "Transport Layer Security (TLS)
	Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,		Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
	<http://www.rfc-editor.org/info/rfc4366>.		<http://www.rfc-editor.org/info/rfc4366>.
	Authors' Addresses		Authors' Addresses
	Cullen Jennings		Cullen Jennings
End of changes. 63 change blocks.
	115 lines changed or deleted		163 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/