draft-ietf-perc-dtls-tunnel-09.txt		draft-ietf-perc-dtls-tunnel-10.txt
	Network Working Group P. Jones		Network Working Group P. Jones
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Informational P. Ellenbogen		Intended status: Informational P. Ellenbogen
	Expires: 15 December 2021 Princeton University		Expires: 28 March 2022 Princeton University
	N. Ohlmeier		N. Ohlmeier
	8x8, Inc.		8x8, Inc.
	13 June 2021		24 September 2021
	DTLS Tunnel between a Media Distributor and Key Distributor to		DTLS Tunnel between a Media Distributor and Key Distributor to
	Facilitate Key Exchange		Facilitate Key Exchange
	draft-ietf-perc-dtls-tunnel-09		draft-ietf-perc-dtls-tunnel-10
	Abstract		Abstract
	This document defines a DTLS tunneling protocol for use in multimedia		This document defines a protocol for tunneling DTLS traffic in
	conferences that enables a Media Distributor to facilitate key		multimedia conferences that enables a Media Distributor to facilitate
	exchange between an endpoint in a conference and the Key Distributor.		key exchange between an endpoint in a conference and the Key
	The protocol is designed to ensure that the keying material used for		Distributor. The protocol is designed to ensure that the keying
	hop-by-hop encryption and authentication is accessible to the Media		material used for hop-by-hop encryption and authentication is
	Distributor, while the keying material used for end-to-end encryption		accessible to the Media Distributor, while the keying material used
	and authentication is inaccessible to the Media Distributor.		for end-to-end encryption and authentication is inaccessible to the
			Media Distributor.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 15 December 2021.		This Internet-Draft will expire on 28 March 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used In This Document . . . . . . . . . . . . . . 3		2. Conventions Used In This Document . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 39 ¶
	6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12		6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12
	6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12		6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12
	6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13		6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13
	6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13		6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13
	7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13		7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 15		9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	11. Normative References . . . . . . . . . . . . . . . . . . . . 16		11. Normative References . . . . . . . . . . . . . . . . . . . . 16
	12. Informative References . . . . . . . . . . . . . . . . . . . 17		12. Informative References . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is		An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is
	to ensure that endpoints in a multimedia conference have access to		to ensure that endpoints in a multimedia conference have access to
	the end-to-end (E2E) and hop-by-hop (HBH) keying material used to		the end-to-end (E2E) and hop-by-hop (HBH) keying material used to
	encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550]		encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550]
	packets, while the Media Distributor has access only to the HBH		packets, while the Media Distributor has access only to the HBH
	keying material for encryption and authentication.		keying material for encryption and authentication.
			[RFC EDITOR: References to RFC 6347 can be changed to the RFC for
			DTLS 1.3 if available.]
	This specification defines a tunneling protocol that enables the		This specification defines a tunneling protocol that enables the
	Media Distributor to tunnel DTLS [RFC6347] messages between an		Media Distributor to tunnel DTLS [RFC6347] messages between an
	endpoint and the Key Distributor, thus allowing an endpoint to use		endpoint and a Key Distributor, thus allowing an endpoint to use
	DTLS-SRTP [RFC5764] for establishing encryption and authentication		DTLS-SRTP [RFC5764] for establishing encryption and authentication
	keys with the Key Distributor.		keys with the Key Distributor.
	The tunnel established between the Media Distributor and Key		The tunnel established between the Media Distributor and Key
	Distributor is a TLS [RFC5246] connection that is established before		Distributor is a TLS [RFC8446] connection that is established before
	any messages are forwarded by the Media Distributor on behalf of the		any messages are forwarded by the Media Distributor on behalf of
	endpoint. DTLS packets received from the endpoint are encapsulated		endpoints. DTLS packets received from an endpoint are encapsulated
	by the Media Distributor inside this tunnel as data to be sent to the		by the Media Distributor inside this tunnel as data to be sent to the
	Key Distributor. Likewise, when the Media Distributor receives data		Key Distributor. Likewise, when the Media Distributor receives data
	from the Key Distributor over the tunnel, it extracts the DTLS		from the Key Distributor over the tunnel, it extracts the DTLS
	message inside and forwards the DTLS message to the endpoint. In		message inside and forwards the DTLS message to the endpoint. In
	this way, the DTLS association for the DTLS-SRTP procedures is		this way, the DTLS association for the DTLS-SRTP procedures is
	established between the endpoint and the Key Distributor, with the		established between an endpoint and the Key Distributor, with the
	Media Distributor simply forwarding packets between the two entities		Media Distributor forwarding DTLS messages between the two entities
	and having no visibility into the confidential information exchanged.		via the established tunnel to the Key Distributor and having no
			visibility into the confidential information exchanged.
	Following the existing DTLS-SRTP procedures, the endpoint and Key		Following the existing DTLS-SRTP procedures, the endpoint and Key
	Distributor will arrive at a selected cipher and keying material,		Distributor will arrive at a selected cipher and keying material,
	which are used for HBH encryption and authentication by both the		which are used for HBH encryption and authentication by both the
	endpoint and the Media Distributor. However, since the Media		endpoint and the Media Distributor. However, since the Media
	Distributor would not have direct access to this information, the Key		Distributor would not have direct access to this information, the Key
	Distributor explicitly shares the HBH key information with the Media		Distributor explicitly shares the HBH key information with the Media
	Distributor via the tunneling protocol defined in this document.		Distributor via the tunneling protocol defined in this document.
	Additionally, the endpoint and Key Distributor will agree on a cipher		Additionally, the endpoint and Key Distributor will agree on a cipher
	for E2E encryption and authentication. The Key Distributor will		for E2E encryption and authentication. The Key Distributor will
	transmit keying material to the endpoint for E2E operations, but will		transmit keying material to the endpoint for E2E operations, but will
	not share that information with the Media Distributor.		not share that information with the Media Distributor.
	By establishing this TLS tunnel between the Media Distributor and Key		By establishing this TLS tunnel between the Media Distributor and Key
	Distributor and implementing the protocol defined in this document,		Distributor and implementing the protocol defined in this document,
	it is possible for the Media Distributor to facilitate the		it is possible for the Media Distributor to facilitate the
	establishment of a secure DTLS association between an endpoint and		establishment of a secure DTLS association between an endpoint and
	the Key Distributor in order for the endpoint to receive E2E and HBH		the Key Distributor in order for the endpoint to generate E2E and HBH
	keying material. At the same time, the Key Distributor can securely		keying material. At the same time, the Key Distributor can securely
	provide the HBH keying material to the Media Distributor.		provide the HBH keying material to the Media Distributor.
	2. Conventions Used In This Document		2. Conventions Used In This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 46 ¶
	SRTP protection profiles supported by the Media Distributor will be		SRTP protection profiles supported by the Media Distributor will be
	sent in a "SupportedProfiles" message when the TLS tunnel is		sent in a "SupportedProfiles" message when the TLS tunnel is
	initially established. The Key Distributor will use that information		initially established. The Key Distributor will use that information
	to select a common profile supported by both the endpoint and the		to select a common profile supported by both the endpoint and the
	Media Distributor to ensure that HBH operations can be successfully		Media Distributor to ensure that HBH operations can be successfully
	performed.		performed.
	As DTLS messages are received from the endpoint by the Media		As DTLS messages are received from the endpoint by the Media
	Distributor, they are forwarded to the Key Distributor encapsulated		Distributor, they are forwarded to the Key Distributor encapsulated
	inside a "TunneledDtls" message. Likewise, as "TunneledDtls"		inside a "TunneledDtls" message. Likewise, as "TunneledDtls"
	messages are received by the Media Distributor from the Mey		messages are received by the Media Distributor from the Key
	Distributor, the encapsulated DTLS packet is forwarded to the		Distributor, the encapsulated DTLS packet is forwarded to the
	endpoint.		endpoint.
	The Key Distributor will provide the SRTP [RFC3711] keying material		The Key Distributor will provide the SRTP [RFC3711] keying material
	to the Media Distributor for HBH operations via the "MediaKeys"		to the Media Distributor for HBH operations via the "MediaKeys"
	message. The Media Distributor will extract this keying material		message. The Media Distributor will extract this keying material
	from the "MediaKeys" message when received and use it for HBH		from the "MediaKeys" message when received and use it for HBH
	encryption and authentication.		encryption and authentication.
	5. Tunneling Procedures		5. Tunneling Procedures
	The following sub-sections explain in detail the expected behavior of		The following sub-sections explain in detail the expected behavior of
	the endpoint, the Media Distributor, and the Key Distributor.		the endpoint, the Media Distributor, and the Key Distributor.
	It is important to note that the tunneling protocol described in this		It is important to note that the tunneling protocol described in this
	document is not an extension to TLS [RFC5246] or DTLS [RFC6347].		document is not an extension to TLS [RFC8446] or DTLS [RFC6347].
	Rather, it is a protocol that transports DTLS messages generated by		Rather, it is a protocol that transports DTLS messages generated by
	an endpoint or Key Distributor as data inside of the TLS connection		an endpoint or Key Distributor as data inside of the TLS connection
	established between the Media Distributor and Key Distributor.		established between the Media Distributor and Key Distributor.
	5.1. Endpoint Procedures		5.1. Endpoint Procedures
	The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764]		The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764]
	in order to establish the cipher and keys used for encryption and		in order to establish the cipher and keys used for encryption and
	authentication, with the endpoint acting as the client and the Key		authentication, with the endpoint acting as the client and the Key
	Distributor acting as the server. The endpoint does not need to be		Distributor acting as the server. The endpoint does not need to be
	aware of the fact that DTLS messages it transmits toward the Media		aware of the fact that DTLS messages it transmits toward the Media
	Distributor are being tunneled to the Key Distributor.		Distributor are being tunneled to the Key Distributor.
	The endpoint MUST include a unique identifier in the "tls-id" SDP		The endpoint MUST include a unique identifier in the "tls-id" SDP
	[RFC4566] attribute sent by the endpoint in both offer and answer		[RFC4566] attribute in all offer and answer messages [RFC3264] that
	[RFC3264] messages as per [RFC8842]. Further, the endpoint MUST		it generates as per [RFC8842]. Further, the endpoint MUST include
	include this same unique identifier in the "external_session_id"		this same unique identifier in the "external_session_id" extension
	extension [RFC8844] in the "ClientHello" message when establishing a		[RFC8844] in the "ClientHello" message when establishing a DTLS
	DTLS association.		association.
	When receiving a "external_session_id" value from the Key		When receiving a "external_session_id" value from the Key
	Distributor, the client MUST check to ensure that value matches the		Distributor, the client MUST check to ensure that value matches the
	"tls-id" value received in SDP. If the values do not match, the		"tls-id" value received in SDP. If the values do not match, the
	endpoint MUST consider any received keying material to be invalid and		endpoint MUST consider any received keying material to be invalid and
	terminate the DTLS association.		terminate the DTLS association.
	5.2. Tunnel Establishment Procedures		5.2. Tunnel Establishment Procedures
	Either the Media Distributor or Key Distributor initiates the		Either the Media Distributor or Key Distributor initiates the
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	When the Media Distributor relays a DTLS message from an endpoint,		When the Media Distributor relays a DTLS message from an endpoint,
	the Media Distributor will include an association identifier that is		the Media Distributor will include an association identifier that is
	unique per endpoint-originated DTLS association. The association		unique per endpoint-originated DTLS association. The association
	identifier remains constant for the life of the DTLS association.		identifier remains constant for the life of the DTLS association.
	The Key Distributor identifies each distinct endpoint-originated DTLS		The Key Distributor identifies each distinct endpoint-originated DTLS
	association by the association identifier.		association by the association identifier.
	When processing an incoming endpoint association, the Key Distributor		When processing an incoming endpoint association, the Key Distributor
	MUST extract the "external_session_id" value transmitted in the		MUST extract the "external_session_id" value transmitted in the
	"ClientHello" message and match that against "tls-id" value the		"ClientHello" message and match that against the "tls-id" value the
	endpoint transmitted via SDP. If the values in SDP and the		endpoint transmitted via SDP. If the values in SDP and the
	"ClientHello" do not match, the DTLS association MUST be rejected.		"ClientHello" do not match, the DTLS association MUST be rejected.
	The process through which the "tls-id" in SDP is conveyed to the Key		The process through which the "tls-id" in SDP is conveyed to the Key
	Distributor is outside the scope of this document.		Distributor is outside the scope of this document.
	The Key Distributor MUST match the certificate fingerprint and		The Key Distributor MUST match the certificate fingerprint [RFC4572]
	"external_session_id" received from endpoint's "ClientHello" message		and "external_session_id" received from endpoint's "ClientHello"
	with the values received from the SDP transmitted by the endpoint.		message with the values received from the SDP transmitted by the
	It is through this process that the Key Distributor can be sure to		endpoint [RFC8122]. It is through this process that the Key
	deliver the correct conference key to the endpoint.		Distributor can be sure to deliver the correct conference key to the
			endpoint.
	When sending the "ServerHello" message, the Key Distributor MUST		When sending the "ServerHello" message, the Key Distributor MUST
	insert its own unique identifier in the "external_session_id"		insert its own unique identifier in the "external_session_id"
	extension. This value MUST also be conveyed back to the client via		extension. This value MUST also be conveyed back to the client via
	SDP as a "tls-id" attribute.		SDP as a "tls-id" attribute.
	The Key Distributor MUST encapsulate any DTLS message it sends to an		The Key Distributor MUST encapsulate any DTLS message it sends to an
	endpoint inside a "TunneledDtls" message (see Section 6). The Key		endpoint inside a "TunneledDtls" message (see Section 6). The Key
	Distributor is not required to transmit all messages a given DTLS		Distributor is not required to transmit all messages for a given DTLS
	association through the same tunnel if more than one tunnel has been		association through the same tunnel if more than one tunnel has been
	established between it and a Media Distributor.		established between it and the Media Distributor.
	The Key Distributor MUST use the same association identifier in		The Key Distributor MUST use the same association identifier in
	messages sent to an endpoint as was received in messages from that		messages sent to an endpoint as was received in messages from that
	endpoint. This ensures the Media Distributor can forward the		endpoint. This ensures the Media Distributor can forward the
	messages to the correct endpoint.		messages to the correct endpoint.
	The Key Distributor extracts tunneled DTLS messages from an endpoint		The Key Distributor extracts tunneled DTLS messages from an endpoint
	and acts on those messages as if that endpoint had established the		and acts on those messages as if that endpoint had established the
	DTLS association directly with the Key Distributor. The Key		DTLS association directly with the Key Distributor. The Key
	Distributor is acting as the DTLS server and the endpoint is acting		Distributor is acting as the DTLS server and the endpoint is acting
	as the DTLS client. The handling of the messages and certificates is		as the DTLS client. The handling of the messages and certificates is
	exactly the same as normal DTLS-SRTP procedures between endpoints.		exactly the same as normal DTLS-SRTP procedures between endpoints.
	The Key Distributor MUST send a "MediaKeys" message to the Media		The Key Distributor MUST send a "MediaKeys" message to the Media
	Distributor as soon as the HBH encryption key is computed and before		Distributor as soon as a HBH encryption key is computed. The
	it sends a DTLS "Finished" message to the endpoint. The "MediaKeys"		"MediaKeys" message includes the selected cipher (i.e. protection
	message includes the selected cipher (i.e. protection profile), MKI		profile), MKI [RFC3711] value (if any), SRTP master keys, and SRTP
	[RFC3711] value (if any), SRTP master keys, and SRTP master salt		master salt values. The Key Distributor MUST use the same
	values. The Key Distributor MUST use the same association identifier		association identifier in the "MediaKeys" message as is used in the
	in the "MediaKeys" message as is used in the "TunneledDtls" messages		"TunneledDtls" messages for the given endpoint.
	for the given endpoint.
	The Key Distributor uses the certificate fingerprint of the endpoint		The Key Distributor uses the certificate fingerprint of the endpoint
	along with the unique identifier received in the		along with the unique identifier received in the
	"external_session_id" extension to determine which conference a given		"external_session_id" extension to determine which conference a given
	DTLS association is associated.		DTLS association is associated.
	The Key Distributor MUST select a cipher that is supported by both		The Key Distributor MUST select a cipher that is supported itself,
	the endpoint and the Media Distributor to ensure proper HBH		the endpoint, and the Media Distributor to ensure proper HBH
	operations.		operations.
	When the DTLS association between the endpoint and the Key		When the DTLS association between the endpoint and the Key
	Distributor is terminated, regardless of which entity initiated the		Distributor is terminated, regardless of which entity initiated the
	termination, the Key Distributor MUST send an "EndpointDisconnect"		termination, the Key Distributor MUST send an "EndpointDisconnect"
	message with the association identifier assigned to the endpoint to		message with the association identifier assigned to the endpoint to
	the Media Distributor.		the Media Distributor.
	5.5. Versioning Considerations		5.5. Versioning Considerations
	skipping to change at page 10, line 19 ¶		skipping to change at page 10, line 19 ¶
	If that version is not supported by the Key Distributor, the Key		If that version is not supported by the Key Distributor, the Key
	Distributor MUST transmit an "UnsupportedVersion" message containing		Distributor MUST transmit an "UnsupportedVersion" message containing
	the highest version number supported, and close the TLS connection.		the highest version number supported, and close the TLS connection.
	The Media Distributor MUST take note of the version received in an		The Media Distributor MUST take note of the version received in an
	"UnsupportedVersion" message and use that version when attempting to		"UnsupportedVersion" message and use that version when attempting to
	re-establish a failed tunnel connection. Note that it is not		re-establish a failed tunnel connection. Note that it is not
	necessary for the Media Distributor to understand the newer version		necessary for the Media Distributor to understand the newer version
	of the protocol to understand that the first message received is		of the protocol to understand that the first message received is
	"UnsupportedVersion". The Media Distributor can determine from the		"UnsupportedVersion". The Media Distributor can determine from the
	first two octets received what the version number is and that the		first four octets received what the version number is and that the
	message is "UnsupportedVersion". The rest of the data received, if		message is "UnsupportedVersion". The rest of the data received, if
	any, would be discarded and the connection closed (if not already		any, would be discarded and the connection closed (if not already
	closed).		closed).
	6. Tunneling Protocol		6. Tunneling Protocol
	Tunneled messages are transported via the TLS tunnel as application		Tunneled messages are transported via the TLS tunnel as application
	data between the Media Distributor and the Key Distributor. Tunnel		data between the Media Distributor and the Key Distributor. Tunnel
	messages are specified using the format described in [RFC5246]		messages are specified using the format described in [RFC8446]
	section 4. As in [RFC5246], all values are stored in network byte		section 3. As in [RFC8446], all values are stored in network byte
	(big endian) order; the uint32 represented by the hex bytes 01 02 03		(big endian) order; the uint32 represented by the hex bytes 01 02 03
	04 is equivalent to the decimal value 16909060.		04 is equivalent to the decimal value 16909060.
	This protocol defines several different messages, each of which		This protocol defines several different messages, each of which
	contains the following information:		contains the following information:
	* Message type identifier		* Message type identifier
	* Message body length		* Message body length
	skipping to change at page 11, line 47 ¶		skipping to change at page 11, line 47 ¶
	"TunnelMessage" structure.		"TunnelMessage" structure.
	6.2. SupportedProfiles Message		6.2. SupportedProfiles Message
	The "SupportedProfiles" message is defined as:		The "SupportedProfiles" message is defined as:
	uint8 SRTPProtectionProfile[2]; /* from RFC5764 */		uint8 SRTPProtectionProfile[2]; /* from RFC5764 */
	struct {		struct {
	uint8 version;		uint8 version;
	SRTPProtectionProfile protection_profiles<0..2^16-1>;		SRTPProtectionProfile protection_profiles<2..2^16-1>;
	} SupportedProfiles;		} SupportedProfiles;
	This message contains this single element:		This message contains this single element:
	* "version": indicates the version of the protocol to use (0x00).		* "version": This document specifies version 0x00.
	* "protection_profiles": The list of two-octet SRTP protection		* "protection_profiles": The list of two-octet SRTP protection
	profile values as per [RFC5764] supported by the Media		profile values as per [RFC5764] supported by the Media
	Distributor.		Distributor.
	6.3. UnsupportedVersion Message		6.3. UnsupportedVersion Message
	The "UnsupportedVersion" message is defined as follows:		The "UnsupportedVersion" message is defined as follows:
	struct {		struct {
	skipping to change at page 13, line 44 ¶		skipping to change at page 13, line 44 ¶
	} EndpointDisconnect;		} EndpointDisconnect;
	The fields are described as follows:		The fields are described as follows:
	* "association_id": An value that identifies a distinct DTLS		* "association_id": An value that identifies a distinct DTLS
	association between an endpoint and the Key Distributor.		association between an endpoint and the Key Distributor.
	7. Example Binary Encoding		7. Example Binary Encoding
	The "TunnelMessage" is encoded in binary following the procedures		The "TunnelMessage" is encoded in binary following the procedures
	specified in [RFC5246]. This section provides an example of what the		specified in [RFC8446]. This section provides an example of what the
	bits on the wire would look like for the "SupportedProfiles" message		bits on the wire would look like for the "SupportedProfiles" message
	that advertises support for both		that advertises support for both
	"DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and		"DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and
	"DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723].		"DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723].
	TunnelMessage:		TunnelMessage:
	message_type: 0x01		message_type: 0x01
	length: 0x0007		length: 0x0007
	SupportedProfiles:		SupportedProfiles:
	version: 0x00		version: 0x00
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	The value 0x00 is reserved and all values in the range 0x06 to 0xFF		The value 0x00 is reserved and all values in the range 0x06 to 0xFF
	are available for allocation. The procedures for updating this table		are available for allocation. The procedures for updating this table
	are those defined as "IETF Review" in section 4.8 of [RFC8126].		are those defined as "IETF Review" in section 4.8 of [RFC8126].
	The name for this registry is "Datagram Transport Layer Security		The name for this registry is "Datagram Transport Layer Security
	(DTLS) Tunnel Protocol Message Types for Privacy Enhanced		(DTLS) Tunnel Protocol Message Types for Privacy Enhanced
	Conferencing".		Conferencing".
	9. Security Considerations		9. Security Considerations
	Since the procedures in this document relies on TLS [RFC5246] for		Since the procedures in this document relies on TLS [RFC8446] for
	transport security, the security considerations for TLS should be		transport security, the security considerations for TLS should be
	reviewed when implementing the protocol defined in this document.		reviewed when implementing the protocol defined in this document.
	While the tunneling protocol defined in this document does not use		While the tunneling protocol defined in this document does not use
	DTLS-SRTP [[RFC5764] directly, it does convey and negotiate some of		DTLS-SRTP [[RFC5764] directly, it does convey and negotiate some of
	the same information (e.g., protection profile data). As such, a		the same information (e.g., protection profile data). As such, a
	review of the security considerations found in that document may be		review of the security considerations found in that document may be
	useful.		useful.
	This document describes a means of securely exchanging keying		This document describes a means of securely exchanging keying
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	the protocol defined in this document, the Media Distributor has no		the protocol defined in this document, the Media Distributor has no
	means of gaining access to that information and therefore cannot		means of gaining access to that information and therefore cannot
	affect the E2E media processing function in the endpoint except to		affect the E2E media processing function in the endpoint except to
	present it with invalid or replayed data. That said, any entity		present it with invalid or replayed data. That said, any entity
	along the path that interferes with the DTLS exchange between the		along the path that interferes with the DTLS exchange between the
	endpoint and the Key Distributor, including a malicious Media		endpoint and the Key Distributor, including a malicious Media
	Distributor that is not properly authorized, could prevent an		Distributor that is not properly authorized, could prevent an
	endpoint from properly communicating with the Key Distributor and,		endpoint from properly communicating with the Key Distributor and,
	therefore, prevent successful conference participation.		therefore, prevent successful conference participation.
			The Key Distributor should be aware of the possibility that a
			malicious Media Distributor might transmit an "EndpointDisconnect"
			message to the Key Distributor when the endpoint is, in fact, still
			connected.
			While the Security Considerations section of [RFC8871] describes
			various attacks one needs to consider with respect to the Key
			Distributor and denial-of-service, use of this protocol introduces
			another possible attack vector. Consider the case where a malicious
			endpoint sends unsolicited DTLS-SRTP messages to a Media Distributor.
			The Media Distributor will normally forward those messages to the Key
			Distributor and, if found invalid, such messages only serve to
			consume resources on both the Media Distributor and Key Distributor.
	10. Acknowledgments		10. Acknowledgments
	The author would like to thank David Benham and Cullen Jennings for		The author would like to thank David Benham and Cullen Jennings for
	reviewing this document and providing constructive comments.		reviewing this document and providing constructive comments.
	11. Normative References		11. 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/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	skipping to change at page 16, line 36 ¶		skipping to change at page 17, line 5 ¶
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005,		DOI 10.17487/RFC4122, July 2005,
	<https://www.rfc-editor.org/info/rfc4122>.		<https://www.rfc-editor.org/info/rfc4122>.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, DOI 10.17487/RFC4566,		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
	July 2006, <https://www.rfc-editor.org/info/rfc4566>.		July 2006, <https://www.rfc-editor.org/info/rfc4566>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
	(TLS) Protocol Version 1.2", RFC 5246,		Transport Layer Security (TLS) Protocol in the Session
	DOI 10.17487/RFC5246, August 2008,		Description Protocol (SDP)", RFC 4572,
	<https://www.rfc-editor.org/info/rfc5246>.		DOI 10.17487/RFC4572, July 2006,
			<https://www.rfc-editor.org/info/rfc4572>.
	[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 10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010,
	<https://www.rfc-editor.org/info/rfc5764>.		<https://www.rfc-editor.org/info/rfc5764>.
			[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
			Transport over the Transport Layer Security (TLS) Protocol
			in the Session Description Protocol (SDP)", RFC 8122,
			DOI 10.17487/RFC8122, March 2017,
			<https://www.rfc-editor.org/info/rfc8122>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol		[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol
	(SDP) Offer/Answer Considerations for Datagram Transport		(SDP) Offer/Answer Considerations for Datagram Transport
	Layer Security (DTLS) and Transport Layer Security (TLS)",		Layer Security (DTLS) and Transport Layer Security (TLS)",
	RFC 8842, DOI 10.17487/RFC8842, January 2021,		RFC 8842, DOI 10.17487/RFC8842, January 2021,
	<https://www.rfc-editor.org/info/rfc8842>.		<https://www.rfc-editor.org/info/rfc8842>.
	[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on		[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
	Uses of TLS with the Session Description Protocol (SDP)",		Uses of TLS with the Session Description Protocol (SDP)",
	RFC 8844, DOI 10.17487/RFC8844, January 2021,		RFC 8844, DOI 10.17487/RFC8844, January 2021,
	<https://www.rfc-editor.org/info/rfc8844>.		<https://www.rfc-editor.org/info/rfc8844>.
	[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution
	Framework for Private Media in Privacy-Enhanced RTP
	Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
	January 2021, <https://www.rfc-editor.org/info/rfc8871>.
	12. Informative References		12. Informative References
	[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,
	<https://www.rfc-editor.org/info/rfc3711>.		<https://www.rfc-editor.org/info/rfc3711>.
	[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, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,		[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
	"Double Encryption Procedures for the Secure Real-Time		"Double Encryption Procedures for the Secure Real-Time
	Transport Protocol (SRTP)", RFC 8723,		Transport Protocol (SRTP)", RFC 8723,
	DOI 10.17487/RFC8723, April 2020,		DOI 10.17487/RFC8723, April 2020,
	<https://www.rfc-editor.org/info/rfc8723>.		<https://www.rfc-editor.org/info/rfc8723>.
			[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution
			Framework for Private Media in Privacy-Enhanced RTP
			Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
			January 2021, <https://www.rfc-editor.org/info/rfc8871>.
	Authors' Addresses		Authors' Addresses
	Paul E. Jones		Paul E. Jones
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7025 Kit Creek Rd.		7025 Kit Creek Rd.
	Research Triangle Park, North Carolina 27709		Research Triangle Park, North Carolina 27709
	United States of America		United States of America
	Phone: +1 919 476 2048		Phone: +1 919 476 2048
	Email: paulej@packetizer.com		Email: paulej@packetizer.com
End of changes. 33 change blocks.
	61 lines changed or deleted		89 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/