rfc8870v8.txt		rfc8870.txt
	skipping to change at line 206 ¶		skipping to change at line 206 ¶
	but that topic is left for a future specification. SRTP is preferred		but that topic is left for a future specification. SRTP is preferred
	for transmitting keying material because (1) it shares fate with the		for transmitting keying material because (1) it shares fate with the
	transmitted media, (2) SRTP rekeying can occur without concern for		transmitted media, (2) SRTP rekeying can occur without concern for
	RTCP transmission limits, and (3) it avoids the need for SRTCP		RTCP transmission limits, and (3) it avoids the need for SRTCP
	compound packets with RTP translators and mixers.		compound packets with RTP translators and mixers.
	4.1. EKTField Formats		4.1. EKTField Formats
	The EKTField uses the formats defined in Figures 1 and 2 for the		The EKTField uses the formats defined in Figures 1 and 2 for the
	FullEKTField and ShortEKTField. The EKTField appended to an SRTP		FullEKTField and ShortEKTField. The EKTField appended to an SRTP
	packet can be referred to as an "EKT tag".		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 line 294 ¶		skipping to change at line 294 ¶
	On the sender side, this is the SRTP master key associated with		On the sender side, this is the SRTP master key associated with
	the indicated SSRC.		the indicated SSRC.
	SRTPMasterKeyLength:		SRTPMasterKeyLength:
	This is the length of the SRTPMasterKey in bytes. This depends on		This is the length of the SRTPMasterKey in bytes. This depends on
	the cipher suite negotiated for SRTP using Session Description		the cipher suite negotiated for SRTP using Session Description
	Protocol (SDP) Offer/Answer [RFC3264].		Protocol (SDP) Offer/Answer [RFC3264].
	SSRC:		SSRC:
	On the sender side, this is the SSRC for this SRTP source. The		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		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		MUST be the same as the one in the header of the SRTP packet to
	which the tag is appended.		which the tag is appended.
	Rollover Counter (ROC):		Rollover Counter (ROC):
	On the sender side, this is set to the current value of the SRTP		On the sender side, this is set to the current value of the SRTP
	ROC in the SRTP context associated with the SSRC in the SRTP		ROC in the SRTP context associated with the SSRC in the SRTP
	packet. The length of this field is 32 bits.		packet. The length of this field is 32 bits.
	Security Parameter Index (SPI):		Security Parameter Index (SPI):
	This field indicates the appropriate EKTKey and other parameters		This field indicates the appropriate EKTKey and other parameters
	skipping to change at line 344 ¶		skipping to change at line 344 ¶
	EKTMsgLength:		EKTMsgLength:
	All EKT Message Types other than the ShortEKTField include a		All EKT Message Types other than the ShortEKTField include a
	length in octets (in network byte order) of either the		length in octets (in network byte order) of either the
	FullEKTField or the ExtensionEKTField, including this length field		FullEKTField or the ExtensionEKTField, including this length field
	and the EKT Message Type (as defined in the next paragraph).		and the EKT Message Type (as defined in the next paragraph).
	Message Type:		Message Type:
	The last byte is used to indicate the type of the EKTField. This		The last byte is used to indicate the type of the EKTField. This
	MUST be 2 for the FullEKTField format and 0 for the ShortEKTField		MUST be 2 for the FullEKTField format and 0 for the ShortEKTField
	format. If a received EKT tag has an unknown Message Type, then		format. If a received EKT Tag has an unknown Message Type, then
	the receiver MUST discard the whole EKT tag.		the receiver MUST discard the whole EKT Tag.
	4.2. SPIs and EKT Parameter Sets		4.2. SPIs and EKT Parameter Sets
	The SPI identifies the parameters for how the EKT tag should be		The SPI identifies the parameters for how the EKT Tag should be
	processed:		processed:
	* The EKTKey and EKT Cipher used to process the packet.		* The EKTKey and EKT Cipher used to process the packet.
	* The SRTP master salt associated with any master key encrypted with		* The SRTP master salt associated with any master key encrypted with
	this EKT Key. The master salt is communicated separately, via		this EKT Key. The master salt is communicated separately, via
	signaling, typically along with the EKTKey.		signaling, typically along with the EKTKey.
	Together, these data elements are called an "EKT parameter set". To		Together, these data elements are called an "EKT parameter set". To
	avoid ambiguity, each distinct EKT parameter set that is used MUST be		avoid ambiguity, each distinct EKT parameter set that is used MUST be
	skipping to change at line 467 ¶		skipping to change at line 467 ¶
	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
	step. If the EKT decryption operation returns an authentication		step. If the EKT decryption operation returns an authentication
	failure, then EKT processing MUST be aborted. The receiver		failure, then EKT processing MUST be aborted. The receiver
	SHOULD discard the whole SRTP packet.		SHOULD discard the whole SRTP 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 (see Section 5.2.2) sent as		If the value of the srtp_master_salt (see Section 5.2.2) sent as
	part of the EKTkey is longer than needed by SRTP, then it is		part of the EKTKey is longer than needed by SRTP, then it is
	truncated by taking the first N bytes from the srtp_master_salt		truncated by taking the first N bytes from the srtp_master_salt
	field.		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 this FullEKTField MUST be discarded		SRTP packet received, then this FullEKTField MUST be discarded
	and the subsequent steps in this list skipped. After stripping		and the subsequent steps in this list skipped. After stripping
	the FullEKTField, the remainder of the SRTP packet MAY be		the FullEKTField, the remainder of the SRTP packet MAY be
	processed as normal.		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
	skipping to change at line 509 ¶		skipping to change at line 509 ¶
	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, SRTP master key, and		packets protected by the same EKT parameter set, SRTP master key, and
	ROC. SRTP senders and receivers MAY cache an EKTCiphertext value to		ROC. SRTP senders and receivers MAY cache an EKTCiphertext value to
	optimize processing in cases where the master key hasn't changed.		optimize processing in cases where the master key hasn't changed.
	Instead of encrypting and decrypting, senders can simply copy the		Instead of encrypting and decrypting, senders can simply copy the
	precomputed value and receivers can compare a received EKTCiphertext		precomputed value and receivers can compare a received EKTCiphertext
	to the known value.		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
	for some time after sending a new key in an EKT tag. Receivers that		for some time after sending a new key in an EKT Tag. Receivers that
	wish to avoid packet loss due to decryption failures MAY perform		wish to avoid packet loss due to decryption failures MAY perform
	trial decryption with both the old key and the new key, keeping the		trial decryption with both the old key and the new key, keeping the
	result of whichever decryption succeeds. Note that this approach is		result of whichever decryption succeeds. Note that this approach is
	only compatible with SRTP transforms that include integrity		only compatible with SRTP transforms that include integrity
	protection.		protection.
	When receiving a new EKTKey, implementations need to use the ekt_ttl		When receiving a new EKTKey, implementations need to use the ekt_ttl
	field (see Section 5.2.2) to create a time after which this key		field (see Section 5.2.2) to create a time after which this key
	cannot be used, and they also need to create a counter that keeps		cannot be used, and they also need to create a counter that keeps
	track of how many times the key has been used to encrypt data, to		track of how many times the key has been used to encrypt data, to
	skipping to change at line 648 ¶		skipping to change at line 648 ¶
	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, ideally in its initial SRTP packet. To		soon as possible, ideally in its initial SRTP packet. To
	accommodate packet loss, it is RECOMMENDED that the FullEKTField		accommodate packet loss, it is RECOMMENDED that the FullEKTField
	be transmitted in three consecutive packets. If the sender does		be transmitted in three consecutive packets. If the sender does
	not send a FullEKTField in its initial packets and receivers have		not send a FullEKTField in its initial packets and receivers have
	not otherwise been provisioned with a decryption key, then		not otherwise been provisioned with a decryption key, then
	decryption will fail and SRTP packets will be dropped until the		decryption will fail and SRTP packets will be dropped until the
	receiver receives a FullEKTField from the sender.		receiver receives a FullEKTField from the sender.
	Rekey:		Rekey:
	By sending an EKT tag over SRTP, the rekeying event shares fate		By sending an EKT Tag over SRTP, the rekeying event shares fate
	with the SRTP packets protected with that new SRTP master key. To		with 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 containing the FullEKTField be transmitted.		packets containing 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). Also, when a new receiver joins a session, the sender		receiver). Also, when a new receiver joins a session, the sender
	is generally unaware of the receiver joining the session; thus,		is generally unaware of the receiver joining the session; thus,
	senders SHOULD periodically transmit the FullEKTField. That		senders SHOULD periodically transmit the FullEKTField. That
	skipping to change at line 689 ¶		skipping to change at line 689 ¶
	from the DTLS-SRTP peer in the server role to the client. This		from the DTLS-SRTP peer in the server role to the client. This
	allows such a peer to process EKT keying material in SRTP and		allows such a peer to process EKT keying material in SRTP and
	retrieve the embedded SRTP keying material. This combination of		retrieve the embedded SRTP keying material. This combination of
	protocols is valuable because it combines the advantages of DTLS,		protocols is valuable because it combines the advantages of DTLS,
	which has strong authentication of the endpoint and flexibility,		which has strong authentication of the endpoint and flexibility,
	along with allowing secure multi-party RTP with loose coordination		along with allowing secure multi-party RTP with loose coordination
	and efficient communication of per-source keys.		and efficient 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 keying material		media relay, the protection that DTLS affords to EKT keying material
	can allow EKT keys to be tunneled through an untrusted relay such as		can allow EKT Keys to be tunneled through an untrusted relay such as
	a centralized conference bridge. For more details, see [RFC8871].		a centralized conference bridge. For more details, see [RFC8871].
	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
	to exchange keying material, algorithms, and parameters for SRTP.		to exchange keying material, algorithms, and parameters for SRTP.
	The SRTP flow operates over the same transport as the DTLS-SRTP		The SRTP flow operates over the same transport as the DTLS-SRTP
	exchange (i.e., the same 5-tuple). DTLS-SRTP combines the		exchange (i.e., the same 5-tuple). DTLS-SRTP combines the
	performance and encryption flexibility benefits of SRTP with the		performance and encryption flexibility benefits of SRTP with the
	flexibility and convenience of DTLS-integrated key and association		flexibility and convenience of DTLS-integrated key and association
	skipping to change at line 742 ¶		skipping to change at line 742 ¶
	<--------		<--------
	{... Finished} -------->		{... Finished} -------->
	[ACK]		[ACK]
	<-------- [EKTKey]		<-------- [EKTKey]
	[ACK] -------->		[ACK] -------->
	|SRTP packets| <-------> |SRTP packets|		|SRTP packets| <-------> |SRTP packets|
	+ <EKT tags> + <EKT tags>		+ <EKT Tags> + <EKT Tags>
	{} Messages protected using DTLS handshake keys		{} Messages protected using DTLS handshake keys
	[] Messages protected using DTLS application traffic keys		[] Messages protected using DTLS application traffic keys
	<> Messages protected using the EKTKey and EKT Cipher		<> Messages protected using the EKTKey and EKT Cipher
	|| Messages protected using the SRTP master key sent in		|| Messages protected using the SRTP master key sent in
	a Full EKT Tag		a Full EKT Tag
	Figure 4: DTLS 1.3 Message Flow		Figure 4: DTLS 1.3 Message Flow
	In the context of a multi-party SRTP session in which each endpoint		In the context of a multi-party SRTP session in which each endpoint
	performs a DTLS handshake as a client with a central DTLS server, the		performs a DTLS handshake as a client with a central DTLS server, the
	extensions defined in this document allow the DTLS server to set a		extensions defined in this document allow the DTLS server to set a
	common EKTKey for all participants. Each endpoint can then use EKT		common EKTKey for all participants. Each endpoint can then use EKT
	tags encrypted with that common key to inform other endpoints of the		Tags encrypted with that common key to inform other endpoints of the
	keys it uses to protect SRTP packets. This avoids the need for many		keys it uses to protect SRTP packets. This avoids the need for many
	individual DTLS handshakes among the endpoints, at the cost of		individual DTLS handshakes among the endpoints, at the cost of
	preventing endpoints from directly authenticating one another.		preventing endpoints from directly authenticating one another.
	Client A Server Client B		Client A Server Client B
	<----DTLS Handshake---->		<----DTLS Handshake---->
	<--------EKTKey---------		<--------EKTKey---------
	<----DTLS Handshake---->		<----DTLS Handshake---->
	---------EKTKey-------->		---------EKTKey-------->
	skipping to change at line 835 ¶		skipping to change at line 835 ¶
	ekt_key_value		ekt_key_value
	The EKTKey that the recipient should use when generating		The EKTKey that the recipient should use when generating
	EKTCiphertext values		EKTCiphertext values
	srtp_master_salt		srtp_master_salt
	The SRTP master salt to be used with any master key encrypted with		The SRTP master salt to be used with any master key encrypted with
	this EKT Key		this EKT Key
	ekt_spi		ekt_spi
	The SPI value to be used to reference this EKTKey and SRTP master		The SPI value to be used to reference this EKTKey and SRTP master
	salt in EKT tags (along with the EKT Cipher negotiated in the		salt in EKT Tags (along with the EKT Cipher negotiated in the
	handshake)		handshake)
	ekt_ttl		ekt_ttl
	The maximum amount of time, in seconds, that this EKTKey can be		The maximum amount of time, in seconds, that this EKTKey can be
	used. The ekt_key_value in this message MUST NOT be used for		used. The ekt_key_value in this message MUST NOT be used for
	encrypting or decrypting information after the TTL expires.		encrypting or decrypting information after the TTL expires.
	If the server did not provide a supported_ekt_ciphers extension in		If the server did not provide a supported_ekt_ciphers extension in
	its EncryptedExtensions (or ServerHello for DTLS 1.2), then EKTKey		its EncryptedExtensions (or ServerHello for DTLS 1.2), then EKTKey
	messages MUST NOT be sent by the client or the server.		messages MUST NOT be sent by the client or the server.
	skipping to change at line 898 ¶		skipping to change at line 898 ¶
	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 reused for any other purpose, and SRTP master keys MUST NOT be		NOT be reused for any other purpose, and SRTP master keys MUST NOT be
	derived from other SRTP master keys.		derived from other SRTP master keys.
	The EKT Cipher includes its own authentication/integrity check.		The EKT Cipher includes its own authentication/integrity check.
	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. This mitigates the impact of cut-and-paste attacks that		SRTP stream. This mitigates the impact of cut-and-paste attacks that
	arise due to the lack of a cryptographic binding between the EKT tag		arise due to the lack of a cryptographic binding between the EKT Tag
	and the rest of the SRTP packet. SRTP tags can only be cut-and-		and the rest of the SRTP packet. SRTP tags can only be cut-and-
	pasted within the stream of packets sent by a given RTP endpoint; an		pasted within the stream of packets sent by a given RTP endpoint; an
	attacker cannot "cross the streams" and use an EKT tag from one SSRC		attacker cannot "cross the streams" and use an EKT Tag from one SSRC
	to reset the key for another SSRC. The Epoch field in the		to reset the key for another SSRC. The Epoch field in the
	FullEKTField also prevents an attacker from rolling back to a		FullEKTField also prevents an attacker from rolling back to a
	previous key.		previous key.
	An attacker could send packets containing a FullEKTField, in an		An attacker could send packets containing a FullEKTField, 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 to decrypt the EKT ciphertext and		by causing the receiving system to 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 4.3.2 helps		previous values of the ciphertext as described in Section 4.3.2 helps
	mitigate this issue.		mitigate this issue.
	skipping to change at line 926 ¶		skipping to change at line 926 ¶
	context, e.g., from a different sender. When the underlying SRTP		context, e.g., from a different sender. When the underlying SRTP
	transform provides integrity protection, this attack will just result		transform provides integrity protection, this attack will just result
	in packet loss. If it does not, then it will result in random data		in packet loss. If it does not, then it will result in random data
	being fed to RTP payload processing. An attacker that is in a		being fed to RTP payload processing. An attacker that is in a
	position to mount these attacks, however, could achieve the same		position to mount these attacks, however, could achieve the same
	effects more easily without attacking EKT.		effects more easily without attacking EKT.
	The key encryption keys distributed with EKTKey messages are group		The key encryption keys distributed with EKTKey messages are group
	shared symmetric keys, which means they do not provide protection		shared symmetric keys, which means they do not provide protection
	within the group. Group members can impersonate each other; for		within the group. Group members can impersonate each other; for
	example, any group member can generate an EKT tag for any SSRC. The		example, any group member can generate an EKT Tag for any SSRC. The
	entity that distributes EKTKeys can decrypt any keys distributed		entity that distributes EKTKeys can decrypt any keys distributed
	using EKT and thus any media protected with those keys.		using EKT and thus any media protected with those keys.
	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 encrypt more		times a given key can be used. An endpoint MUST NOT encrypt more
	than T different FullEKTField values using the same EKTKey. In		than T different FullEKTField values using the same EKTKey. In
	addition, the EKTKey MUST NOT be used beyond the lifetime provided by		addition, the EKTKey MUST NOT be used beyond the lifetime provided by
	the TTL described in Section 5.2.		the TTL described in Section 5.2.
	The key length of the EKT Cipher MUST be at least as long as the SRTP		The key length of the EKT Cipher MUST be at least as long as the SRTP
End of changes. 14 change blocks.
	15 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/