draft-ietf-perc-srtp-ekt-diet-12.txt		draft-ietf-perc-srtp-ekt-diet-13.txt
	Network Working Group C. Jennings		Network Working Group C. Jennings
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track J. Mattsson		Intended status: Standards Track J. Mattsson
	Expires: December 20, 2020 Ericsson AB		Expires: December 25, 2020 Ericsson AB
	D. McGrew		D. McGrew
	Cisco Systems		Cisco Systems
	D. Wing		D. Wing
	Citrix Systems, Inc.		Citrix Systems, Inc.
	F. Andreason		F. Andreason
	Cisco Systems		Cisco Systems
	June 18, 2020		June 23, 2020
	Encrypted Key Transport for DTLS and Secure RTP		Encrypted Key Transport for DTLS and Secure RTP
	draft-ietf-perc-srtp-ekt-diet-12		draft-ietf-perc-srtp-ekt-diet-13
	Abstract		Abstract
	Encrypted Key Transport (EKT) is an extension to DTLS (Datagram		Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
	Transport Layer Security) and Secure Real-time Transport Protocol		Transport Layer Security) and Secure Real-time Transport Protocol
	(SRTP) that provides for the secure transport of SRTP master keys,		(SRTP) that provides for the secure transport of SRTP master keys,
	rollover counters, and other information within SRTP. This facility		rollover counters, and other information within SRTP. This facility
	enables SRTP for decentralized conferences by distributing a common		enables SRTP for decentralized conferences by distributing a common
	key to all of the conference endpoints.		key to all of the conference endpoints.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 20, 2020.		This Internet-Draft will expire on December 25, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Conventions Used In This Document . . . . . . . . . . . . . . 4		3. Conventions Used In This Document . . . . . . . . . . . . . . 4
	4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4		4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4
	4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5		4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5
	4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8		4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8
	4.3. Packet Processing and State Machine . . . . . . . . . . . 8		4.3. Packet Processing and State Machine . . . . . . . . . . . 8
	4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 8		4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 9
	4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10		4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10
	4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12		4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12
	4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13		4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13
	4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13		4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13
	4.6. Timing and Reliability Consideration . . . . . . . . . . 13		4.6. Timing and Reliability Consideration . . . . . . . . . . 13
	5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 14		5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 15
	5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15		5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15
	5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15		5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15
	5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17		5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17
	5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17		5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17
	5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19		5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19
	5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19		5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21		7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21
	7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21		7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	this method, SRTP entities are free to choose SSRC values as they see		this method, SRTP entities are free to choose SSRC values as they see
	fit, and to start up new SRTP sources with new SRTP master keys		fit, and to start up new SRTP sources with new SRTP master keys
	within a session without coordinating with other entities via		within a session without coordinating with other entities via
	external signaling or other external means.		external signaling or other external means.
	EKT extends DTLS and SRTP to enable a common key encryption key		EKT extends DTLS and SRTP to enable a common key encryption key
	(called an EKTKey) to be distributed to all endpoints, so that each		(called an EKTKey) to be distributed to all endpoints, so that each
	endpoint can securely send its SRTP master key and current SRTP		endpoint can securely send its SRTP master key and current SRTP
	rollover counter to the other participants in the session. This data		rollover counter to the other participants in the session. This data
	furnishes the information needed by the receiver to instantiate an		furnishes the information needed by the receiver to instantiate an
	SRTP/SRTCP receiver context.		SRTP receiver context.
	EKT can be used in conferences where the central media distributor or		EKT can be used in conferences where the central media distributor or
	conference bridge cannot decrypt the media, such as the type defined		conference bridge cannot decrypt the media, such as the type defined
	for [I-D.ietf-perc-private-media-framework]. It can also be used for		for [I-D.ietf-perc-private-media-framework]. It can also be used for
	large scale conferences where the conference bridge or media		large scale conferences where the conference bridge or media
	distributor can decrypt all the media but wishes to encrypt the media		distributor can decrypt all the media but wishes to encrypt the media
	it is sending just once and then send the same encrypted media to a		it is sending just once and then send the same encrypted media to a
	large number of participants. This reduces the amount of CPU time		large number of participants. This reduces the amount of CPU time
	needed for encryption and can be used for some optimization to media		needed for encryption and can be used for some optimization to media
	sending that use source specific multicast.		sending that use source specific multicast.
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	This document defines the use of EKT with SRTP. Its use with SRTCP		This document defines the use of EKT with SRTP. Its use with SRTCP
	would be similar, but is reserved for a future specification. SRTP		would be similar, but is reserved for a future specification. SRTP
	is preferred for transmitting key material because it shares fate		is preferred for transmitting key material because it shares fate
	with the transmitted media, because SRTP rekeying can occur without		with the transmitted media, because SRTP rekeying can occur without
	concern for RTCP transmission limits, and because it avoids the need		concern for RTCP transmission limits, and because it avoids the need
	for SRTCP compound packets with RTP translators and mixers.		for SRTCP compound packets with RTP translators and mixers.
	4.1. EKTField Formats		4.1. EKTField Formats
	The EKTField uses the format defined in Figure 1 for the FullEKTField		The EKTField uses the format defined in Figure 1 for the FullEKTField
	and ShortEKTField.		and ShortEKTField. The EKTField appended to an SRTP packet can be
			referred to as an "EKT tag".
	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 | Epoch |		| Security Parameter Index | Epoch |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 49 ¶
	Figure 1: FullEKTField format		Figure 1: FullEKTField 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: ShortEKTField format		Figure 2: ShortEKTField 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 packet. The
	packet. The EKTPlaintext is the concatenation of		EKTPlaintext is the concatenation of SRTPMasterKeyLength,
	SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The		SRTPMasterKey, SSRC, and ROC in that order. The EKTCiphertext is
	EKTCiphertext is computed by encrypting the EKTPlaintext using the		computed by encrypting the EKTPlaintext using the EKTKey. Future
	EKTKey. Future extensions to the EKTField MUST conform to the syntax		extensions to the EKTField MUST conform to the syntax of
	of ExtensionEKTField.		ExtensionEKTField.
	BYTE = %x00-FF		BYTE = %x00-FF
	EKTMsgTypeFull = %x02		EKTMsgTypeFull = %x02
	EKTMsgTypeShort = %x00		EKTMsgTypeShort = %x00
	EKTMsgTypeExtension = %x03-FF		EKTMsgTypeExtension = %x03-FF ; Message type %x01 is reserved, due to
			; usage by legacy implementations.
	EKTMsgLength = 2BYTE;		EKTMsgLength = 2BYTE;
	SRTPMasterKeyLength = BYTE		SRTPMasterKeyLength = BYTE
	SRTPMasterKey = 1*256BYTE		SRTPMasterKey = 1*242BYTE
	SSRC = 4BYTE; SSRC from RTP		SSRC = 4BYTE; SSRC from RTP
	ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC		ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC
	EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC		EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC
	EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)		EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
	Epoch = 2BYTE		Epoch = 2BYTE
	SPI = 2BYTE		SPI = 2BYTE
	FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull		FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull
	ShortEKTField = EKTMsgTypeShort		ShortEKTField = EKTMsgTypeShort
	ExtensionData = 1*1024BYTE		ExtensionData = 1*1024BYTE
	ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension		ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension
	EKTField = FullEKTField / ShortEKTField / ExtensionEKTField		EKTField = FullEKTField / ShortEKTField / ExtensionEKTField
	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 operation.		EKTPlaintext: The data that is input to the EKT encryption operation.
	This data never appears on the wire, and is used only in computations		This data never appears on the wire, and is used only in computations
	internal to EKT. This is the concatenation of the SRTP Master Key		internal to EKT. This is the concatenation of the SRTP Master Key
	and its length, the SSRC, and the ROC.		and its length, the SSRC, and the ROC.
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 18 ¶
	SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This		SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This
	depends on the cipher suite negotiated for SRTP using SDP Offer/		depends on the cipher suite negotiated for SRTP using SDP Offer/
	Answer [RFC3264] for the SRTP.		Answer [RFC3264] for the SRTP.
	SSRC: On the sender side, this is the SSRC for this SRTP source. The		SSRC: On the sender side, this is the SSRC for this SRTP source. The
	length of this field is 32 bits. The SSRC value in the EKT tag MUST		length of this field is 32 bits. The SSRC value in the EKT tag MUST
	be the same as the one in the header of the SRTP packet to which the		be the same as the one in the header of the SRTP packet to which the
	tag is appended.		tag is appended.
	Rollover Counter (ROC): On the sender side, this is set to the		Rollover Counter (ROC): On the sender side, this is set to the
	current value of the SRTP rollover counter in the SRTP/SRTCP context		current value of the SRTP rollover counter in the SRTP context
	associated with the SSRC in the SRTP or SRTCP packet. The length of		associated with the SSRC in the SRTP packet. The length of this
	this field is 32 bits.		field is 32 bits.
	Security Parameter Index (SPI): This field indicates the appropriate		Security Parameter Index (SPI): This field indicates the appropriate
	EKTKey and other parameters for the receiver to use when processing		EKTKey and other parameters for the receiver to use when processing
	the packet, within a given conference. The length of this field is		the packet, within a given conference. The length of this field is
	16 bits, representing a two-byte integer in network byte order. The		16 bits, representing a two-byte integer in network byte order. The
	parameters identified by this field are:		parameters identified by this field are:
	o The EKT cipher used to process the packet.		o The EKT cipher used to process the packet.
	o The EKTKey used to process the packet.		o The EKTKey used to process the packet.
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 32 ¶
	signaling, typically along with the EKTKey.		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 with		Each distinct EKT parameter set that is used MUST be associated with
	a distinct SPI value to avoid ambiguity. The association of a given		a distinct SPI value to avoid ambiguity. The association of a given
	parameter set with a given SPI value is configured by some other		parameter set with a given SPI value is configured by some other
	protocol, e.g., the DTLS-SRTP extension defined in Section 5.		protocol, e.g., the DTLS-SRTP extension defined in Section 5.
	4.3. Packet Processing and State Machine		4.3. Packet Processing and State Machine
	At any given time, each SRTP/SRTCP source has associated with it a		At any given time, each SRTP source has associated with it a single
	single EKT parameter set. This parameter set is used to process all		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 sources in the same session, including other SRTP sources on the
	sources on the same endpoint (e.g., one endpoint with voice and video		same endpoint (e.g., one endpoint with voice and video might have two
	might have two EKT parameter sets, or there might be multiple video		EKT parameter sets, or there might be multiple video sources on an
	sources on an endpoint each with their own EKT parameter set). All		endpoint each with their own EKT parameter set). All of the received
	of the received EKT parameter sets SHOULD be stored by all of the		EKT parameter sets SHOULD be stored by all of the participants in an
	participants in an SRTP session, for use in processing inbound SRTP		SRTP session, for use in processing inbound SRTP traffic. If a
	and SRTCP traffic. If a participant deletes an EKT parameter set		participant deletes an EKT parameter set (e.g., because of space
	(e.g., because of space limitations, then it will be unable to		limitations, then it will be unable to process Full EKT Tags
	process Full EKT Tags containing updated media keys, and thus unable		containing updated media keys, and thus unable to receive media from
	to receive media from a particpant that has changed its media key.		a particpant that has changed its media key.
	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. The decision on which to send when is specified		of all SRTP packets. The decision on which to send when is specified
	in Section 4.6.		in Section 4.6.
	4.3.1. Outbound Processing		4.3.1. Outbound Processing
	See Section 4.6 which describes when to send an SRTP packet with a		See Section 4.6 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 is sent so the receiver can correctly determine how to		ShortEKTField is sent so the receiver can correctly determine how to
	process the packet.		process the packet.
	When an SRTP packet is sent with a FullEKTField, the EKTField for		When an SRTP packet is sent with a FullEKTField, the EKTField 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.
	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 4.1. The ROC, SRTP		SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP
	Master Key, and SSRC used in EKT processing MUST be the same as		Master Key, and SSRC used in EKT processing MUST be the same as
	the one used in the SRTP processing.		the one used in the SRTP processing.
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 11 ¶
	value of 250ms is chosen to represent a reasonable upper bound on the		value of 250ms is chosen to represent a reasonable upper bound on the
	amount of latency and jitter that is tolerable in a real-time		amount of latency and jitter that is tolerable in a real-time
	context.)		context.)
	4.3.2. Inbound Processing		4.3.2. Inbound Processing
	When receiving a packet on a RTP stream, the following steps are		When receiving a packet on a RTP stream, the following steps are
	applied for each SRTP received packet.		applied for each SRTP 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 packet contains a ShortEKTField, the
	ShortEKTField is removed from the packet then normal SRTP or		ShortEKTField is removed from the packet then normal SRTP
	SRTCP processing occurs. If the packet contains a FullEKTField,		processing occurs. If the packet contains a FullEKTField, then
	then processing continues as described below. The reason for		processing continues as described below. The reason for using
	using the last byte of the packet to indicate the type is that		the last byte of the packet to indicate the type is that the
	the length of the SRTP or SRTCP part is not known until the		length of the SRTP part is not known until the decryption has
	decryption has occurred. At this point in the processing, there		occurred. At this point in the processing, there is no easy way
	is no easy way to know where the EKTField would start. However,		to know where the EKTField would start. However, the whole UDP
	the whole UDP packet has been received, so instead of the		packet has been received, so instead of the starting at the front
	starting at the front of the packet, the parsing works backwards		of the packet, the parsing works backwards at the end of the
	at the end of the packet and thus the type is placed at the very		packet and thus the type is placed at the very end of the packet.
	end of the packet.
	2. The Security Parameter Index (SPI) field is used to find the		2. The Security Parameter Index (SPI) field is used to find the
	right EKT parameter set to be used for processing the packet. If		right EKT parameter set to be used for 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 the SRTP Master Salt.		contains the EKTKey, EKTCipher, and the SRTP Master Salt.
	3. The EKTCiphertext is authenticated and decrypted, as described in		3. The EKTCiphertext is authenticated and decrypted, as described in
	Section 4.4, using the EKTKey and EKTCipher found in the previous		Section 4.4, using the EKTKey and EKTCipher found in the previous
	skipping to change at page 10, line 45 ¶		skipping to change at page 10, line 44 ¶
	SHOULD discard the whole UDP packet.		SHOULD discard the whole UDP packet.
	4. The resulting EKTPlaintext is parsed as described in Section 4.1,		4. The resulting EKTPlaintext is parsed as described in Section 4.1,
	to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP		to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP
	Master Salt that is associated with the EKTKey is also retrieved.		Master Salt that is associated with the EKTKey is also retrieved.
	If the value of the srtp_master_salt sent as part of the EKTkey		If 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		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. If the SSRC in the EKTPlaintext does not match the SSRC of the		5. If the SSRC in the EKTPlaintext does not match the SSRC of the
	SRTP packet received, then all the information from this		SRTP packet received, then this FullEKTField MUST be discarded
	EKTPlaintext MUST be discarded and the following steps in this		and the following steps in this list skipped. After stripping
	list are skipped.		the FullEKTField, the remainder of the SRTP packet MAY be
			processed as normal.
	6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous		6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous
	steps are saved in a map indexed by the SSRC found in the		steps 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.		the inbound packets with that SSRC.
	* Unless the transform specifies other acceptable key lengths,		* Unless the transform specifies other acceptable key lengths,
	the length of the SRTP Master Key MUST be the same as the		the length of the SRTP Master Key MUST be the same as the
	master key length for the SRTP transform in use. If this is		master key length for the SRTP transform in use. If this is
	not the case, then the receiver MUST abort EKT processing and		not the case, then the receiver MUST abort EKT processing and
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 21 ¶
	* If the length of the SRTP Master Key is less than the master		* If the length of the SRTP Master Key is less than the master
	key length for the SRTP transform in use, and the transform		key length for the SRTP transform in use, and the transform
	specifies that this length is acceptable, then the SRTP Master		specifies that this length is acceptable, then the SRTP Master
	Key value is used to replace the first bytes in the existing		Key value is used to replace the first bytes in the existing
	master key. The other bytes remain the same as in the old		master key. The other bytes remain the same as in the old
	key. For example, the Double GCM transform		key. For example, the Double GCM transform
	[I-D.ietf-perc-double] allows replacement of the first, "end		[I-D.ietf-perc-double] allows replacement of the first, "end
	to end" half of the master key.		to end" half of the master key.
	7. 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.		normal SRTP processing takes place.
	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. SRTP senders and receivers MAY cache an		master key, and ROC. SRTP senders and receivers MAY cache an
	EKTCiphertext value to optimize processing in cases where the master		EKTCiphertext value to optimize processing in cases where the master
	key hasn't changed. Instead of encrypting and decrypting, senders		key hasn't changed. Instead of encrypting and decrypting, senders
	can simply copy the pre-computed value and receivers can compare a		can simply copy the pre-computed value and receivers can compare a
	received EKTCiphertext to the known value.		received EKTCiphertext to the known value.
	Section 4.3.1 recommends that SRTP senders continue using an old key		Section 4.3.1 recommends that SRTP senders continue using an old key
	skipping to change at page 13, line 39 ¶		skipping to change at page 13, line 39 ¶
	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. The cipher MUST provide integrity protection.		each EKTCipher. The cipher MUST provide integrity protection.
	4.5. Synchronizing Operation		4.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 and eventually begin encrypting with it, as defined
			in Section 4.3.1. 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.
	4.6. Timing and Reliability Consideration		4.6. Timing and Reliability Consideration
	A system using EKT learns the SRTP master keys distributed with the		A system using EKT learns the SRTP master keys distributed with the
	FullEKTField sent with the SRTP, rather than with call signaling. A		FullEKTField 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
	skipping to change at page 14, line 21 ¶		skipping to change at page 14, line 21 ¶
	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.
	The three cases are:		The three cases are:
	New sender:		New sender:
	A new sender SHOULD send a packet containing the FullEKTField as		A new sender SHOULD send a packet containing the FullEKTField as
	soon as possible, always before or coincident with sending its		soon as possible, always before or coincident with sending its
	initial SRTP packet. To accommodate packet loss, it is		initial SRTP packet. To accommodate packet loss, it is
	RECOMMENDED that three consecutive packets contain the		RECOMMENDED that the FullEKTField be transmitted in three
	FullEKTField be transmitted. If the sender does not send a		consecutive packets. If the sender does not send a FullEKTField
	FullEKTField in its initial packets and receivers have not		in its initial packets and receivers have not otherwise been
	otherwise been provisioned with a decryption key, then decryption		provisioned with a decryption key, then decryption will fail and
	will fail and SRTP packets will be dropped until the receiver		SRTP packets will be dropped until the receiver receives a
	receives a FullEKTField from the sender.		FullEKTField from the sender.
	Rekey:		Rekey:
	By sending EKT tag over SRTP, the rekeying event shares fate with		By sending EKT tag over SRTP, the rekeying event shares fate with
	the SRTP packets protected with that new SRTP master key. To		the SRTP packets protected with that new SRTP master key. To
	accommodate packet loss, it is RECOMMENDED that three consecutive		accommodate packet loss, it is RECOMMENDED that three consecutive
	packets contain the FullEKTField be transmitted.		packets contain the FullEKTField be transmitted.
	New receiver:		New receiver:
	When a new receiver joins a session it does not need to		When a new receiver joins a session it does not need to
	communicate its sending SRTP master key (because it is a		communicate its sending SRTP master key (because it is a
	receiver). When a new receiver joins a session, the sender is		receiver). When a new receiver joins a session, the sender is
	generally unaware of the receiver joining the session. Thus,		generally unaware of the receiver joining the session. Thus,
	senders SHOULD periodically transmit the FullEKTField. That		senders SHOULD periodically transmit the FullEKTField. That
	interval depends on how frequently new receivers join the session,		interval depends on how frequently new receivers join the session,
	the acceptable delay before those receivers can start processing		the acceptable delay before those receivers can start processing
	SRTP packets, and the acceptable overhead of sending the		SRTP packets, and the acceptable overhead of sending the
	FullEKTField. If sending audio and video, the RECOMMENDED		FullEKTField. If sending audio and video, the RECOMMENDED
	frequency is the same as the rate of intra coded video frames. If		frequency is the same as the rate of intra coded video frames. If
	only sending audio, the RECOMMENDED frequency is every 100ms.		only sending audio, the RECOMMENDED frequency is every 100ms.
			In general, sending EKT tags less frequently will consume less
			bandwidth, but increase the time it takes for a join or rekey to take
			effect. Applications should schedule the sending of EKT tags in a
			way that makes sense for their bandwidth and latency requirements.
	5. Use of EKT with DTLS-SRTP		5. Use of EKT with DTLS-SRTP
	This document defines an extension to DTLS-SRTP called SRTP EKTKey		This document defines an extension to DTLS-SRTP called SRTP EKTKey
	Transport which enables secure transport of EKT keying material from		Transport which enables secure transport of EKT keying material from
	the DTLS-SRTP peer in the server role to the client. This allows		the DTLS-SRTP peer in the server role to the client. This allows
	those peers to process EKT keying material in SRTP (or SRTCP) and		those peers to process EKT keying material in SRTP and retrieve the
	retrieve the embedded SRTP keying material. This combination of		embedded SRTP keying material. This combination of protocols is
	protocols is valuable because it combines the advantages of DTLS,		valuable because it combines the advantages of DTLS, which has strong
	which has strong authentication of the endpoint and flexibility,		authentication of the endpoint and flexibility, along with allowing
	along with allowing secure multiparty RTP with loose coordination and		secure multiparty RTP with loose coordination and efficient
	efficient communication of per-source keys.		communication of per-source keys.
	In cases where the DTLS termination point is more trusted than the		In cases where the DTLS termination point is more trusted than the
	media relay, the protection that DTLS affords to EKT key material can		media relay, the protection that DTLS affords to EKT key material can
	allow EKT keys to be tunneled through an untrusted relay such as a		allow EKT keys to be tunneled through an untrusted relay such as a
	centralized conference bridge. For more details, see		centralized conference bridge. For more details, see
	[I-D.ietf-perc-private-media-framework].		[I-D.ietf-perc-private-media-framework].
	5.1. DTLS-SRTP Recap		5.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
End of changes. 30 change blocks.
	78 lines changed or deleted		85 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/