rfc8871v8.txt		rfc8871.txt
	skipping to change at line 594 ¶		skipping to change at line 594 ¶
	does accommodate rekeying during the lifetime of a conference.		does accommodate rekeying during the lifetime of a conference.
	When a Key Distributor decides to rekey a conference, it transmits a		When a Key Distributor decides to rekey a conference, it transmits a
	new EKTKey message containing the new EKT Key to each of the		new EKTKey message containing the new EKT Key to each of the
	conference participants. Upon receipt of the new EKT Key, the		conference participants. Upon receipt of the new EKT Key, the
	endpoint MUST create a new SRTP master key and prepare to send that		endpoint MUST create a new SRTP master key and prepare to send that
	key inside a FullEKTField using the new EKT Key as per Section 4.5 of		key inside a FullEKTField using the new EKT Key as per Section 4.5 of
	[RFC8870]. In order to allow time for all endpoints in the		[RFC8870]. In order to allow time for all endpoints in the
	conference to receive the new keys, the sender should follow the		conference to receive the new keys, the sender should follow the
	recommendations in Section 4.6 of [RFC8870]. On receiving a new EKT		recommendations in Section 4.6 of [RFC8870]. On receiving a new EKT
	Key, endpoints MUST be prepared to decrypt EKT tags using the new		Key, endpoints MUST be prepared to decrypt EKT Tags using the new
	key. The EKT Security Parameter Index (SPI) field is used to		key. The EKT Security Parameter Index (SPI) field is used to
	differentiate between EKT Tags encrypted with the old and new keys.		differentiate between EKT Tags encrypted with the old and new keys.
	After rekeying, an endpoint SHOULD retain prior SRTP master keys and		After rekeying, an endpoint SHOULD retain prior SRTP master keys and
	EKT Keys for a period of time sufficient for the purpose of ensuring		EKT Keys for a period of time sufficient for the purpose of ensuring
	that it can decrypt late-arriving or out-of-order packets or packets		that it can decrypt late-arriving or out-of-order packets or packets
	sent by other endpoints that used the prior keys for a period of time		sent by other endpoints that used the prior keys for a period of time
	after rekeying began. An endpoint MAY retain old keys until the end		after rekeying began. An endpoint MAY retain old keys until the end
	of the conference.		of the conference.
	skipping to change at line 791 ¶		skipping to change at line 791 ¶
	EKT Tag data as per [RFC8870]).		EKT Tag data as per [RFC8870]).
	The KEK is not given to the Media Distributor.		The KEK is not given to the Media Distributor.
	6.4. Endpoints Fabricate an SRTP Master Key		6.4. Endpoints Fabricate an SRTP Master Key
	As stated earlier, the E2E key determined via DTLS-SRTP MAY be		As stated earlier, the E2E key determined via DTLS-SRTP MAY be
	discarded in favor of a locally generated E2E SRTP master key. While		discarded in favor of a locally generated E2E SRTP master key. While
	the DTLS-SRTP-derived SRTP master key can be used initially, the		the DTLS-SRTP-derived SRTP master key can be used initially, the
	endpoint might choose to change the SRTP master key periodically and		endpoint might choose to change the SRTP master key periodically and
	MUST change the SRTP master key as a result of the EKT key changing.		MUST change the SRTP master key as a result of the EKT Key changing.
	A locally generated SRTP master key is used along with the master		A locally generated SRTP master key is used along with the master
	salt transmitted to the endpoint from the Key Distributor via the		salt transmitted to the endpoint from the Key Distributor via the
	EKTKey message to encrypt media end to end.		EKTKey message to encrypt media end to end.
	Since the Media Distributor is not involved in E2E functions, it does		Since the Media Distributor is not involved in E2E functions, it does
	not create this key, nor does it have access to any endpoint's E2E		not create this key, nor does it have access to any endpoint's E2E
	key. Note, too, that even the Key Distributor is unaware of the		key. Note, too, that even the Key Distributor is unaware of the
	locally generated E2E keys used by each endpoint.		locally generated E2E keys used by each endpoint.
	skipping to change at line 1203 ¶		skipping to change at line 1203 ¶
	Initiation Protocol (SIP)", RFC 8224,		Initiation Protocol (SIP)", RFC 8224,
	DOI 10.17487/RFC8224, February 2018,		DOI 10.17487/RFC8224, February 2018,
	<https://www.rfc-editor.org/info/rfc8224>.		<https://www.rfc-editor.org/info/rfc8224>.
	[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,		[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
	DOI 10.17487/RFC8827, January 2021,		DOI 10.17487/RFC8827, January 2021,
	<https://www.rfc-editor.org/info/rfc8827>.		<https://www.rfc-editor.org/info/rfc8827>.
	[W3C.CR-webrtc]		[W3C.CR-webrtc]
	Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:		Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
	Real-time Communication Between Browsers", W3C Candidate		Real-time Communication Between Browsers", W3C Proposed
	Recommendation, <https://www.w3.org/TR/webrtc/>.		Recommendation, <https://www.w3.org/TR/webrtc/>.
	Acknowledgments		Acknowledgments
	The authors would like to thank Mo Zanaty, Christian Oien, and		The authors would like to thank Mo Zanaty, Christian Oien, and
	Richard Barnes for invaluable input on this document. Also, we would		Richard Barnes for invaluable input on this document. Also, we would
	like to acknowledge Nermeen Ismail for serving on the initial draft		like to acknowledge Nermeen Ismail for serving on the initial draft
	versions of this document as a coauthor. We would also like to		versions of this document as a coauthor. We would also like to
	acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for		acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for
	providing some of the text in the document, including much of the		providing some of the text in the document, including much of the
End of changes. 3 change blocks.
	3 lines changed or deleted		3 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/