draft-ietf-perc-dtls-tunnel-00.txt		draft-ietf-perc-dtls-tunnel-01.txt
	Network Working Group P. Jones		Network Working Group P. Jones
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track P. Ellenbogen		Intended status: Standards Track P. Ellenbogen
	Expires: September 13, 2017 Princeton University		Expires: October 30, 2017 Princeton University
	N. Ohlmeier		N. Ohlmeier
	Mozilla		Mozilla
	March 12, 2017		April 28, 2017
	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-00		draft-ietf-perc-dtls-tunnel-01
	Abstract		Abstract
	This document defines a DTLS tunneling protocol for use in multimedia		This document defines a DTLS tunneling protocol for use in multimedia
	conferences that enables a Media Distributor to facilitate key		conferences that enables a Media Distributor to facilitate key
	exchange between an endpoint in a conference and the Key Distributor.		exchange between an endpoint in a conference and the Key Distributor.
	The protocol is designed to ensure that the keying material used for		The protocol is designed to ensure that the keying material used for
	hop-by-hop encryption and authentication is accessible to the media		hop-by-hop encryption and authentication is accessible to the media
	distributor, while the keying material used for end-to-end encryption		distributor, while the keying material used for end-to-end encryption
	and authentication is inaccessible to the media distributor.		and authentication is inaccessible to the media distributor.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 13, 2017.		This Internet-Draft will expire on October 30, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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
	3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3		3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3
	4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4		4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4
	5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6		5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6
	5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6		5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6
	5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6		5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6
	5.3. Versioning Considerations . . . . . . . . . . . . . . . . 7		5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7
	5.4. Media Distributor Tunneling Procedures . . . . . . . . . 7		5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8
	5.5. Key Distributor Tunneling Procedures . . . . . . . . . . 9		5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10
	6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10		6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10		6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10
	7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13		7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 15		11.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	An objective of Privacy-Enhanced RTP Conferencing (PERC) is to ensure		An objective of Privacy-Enhanced RTP Conferencing (PERC) is to ensure
	that endpoints in a multimedia conference have access to the end-to-		that endpoints in a multimedia conference have access to the end-to-
	end (E2E) and hop-by-hop (HBH) keying material used to encrypt and		end (E2E) and hop-by-hop (HBH) keying material used to encrypt and
	authenticate Real-time Transport Protocol (RTP) [RFC3550] packets,		authenticate Real-time Transport Protocol (RTP) [RFC3550] packets,
	while the Media Distributor has access only to the hop-by-hop (HBH)		while the Media Distributor has access only to the hop-by-hop (HBH)
	keying material for encryption and authentication.		keying material for encryption and authentication.
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	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 the "sdp_tls_id" DTLS extension
			[I-D.thomson-mmusic-sdp-uks] in the "ClientHello" message when
			establishing a DTLS association. Likewise, the "tls-id" SDP
			[RFC4566] attribute MUST be included in SDP sent by the endpoint in
			both the offer and answer [RFC3264] messages as per
			[I-D.ietf-mmusic-dtls-sdp].
			When receiving a "tls_id" value from the key distributor, the client
			MUST check to ensure that value matches 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 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
	establishment of a TLS tunnel. Which entity acts as the TLS client		establishment of a TLS tunnel. Which entity acts as the TLS client
	when establishing the tunnel and what event triggers the		when establishing the tunnel and what event triggers the
	establishment of the tunnel are outside the scope of this document.		establishment of the tunnel are outside the scope of this document.
	Further, how the trust relationships are established between the key		Further, how the trust relationships are established between the key
	distributor and media distributor are also outside the scope of this		distributor and media distributor are also outside the scope of this
	document.		document.
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 15 ¶
	to the media distributor receiving a DTLS message from an endpoint.		to the media distributor receiving a DTLS message from an endpoint.
	A single tunnel MAY be used to relay DTLS messages between any number		A single tunnel MAY be used to relay DTLS messages between any number
	of endpoints and the key distributor.		of endpoints and the key distributor.
	A media distributor MAY have more than one tunnel established between		A media distributor MAY have more than one tunnel established between
	itself and one or more key distributors. When multiple tunnels are		itself and one or more key distributors. When multiple tunnels are
	established, which tunnel or tunnels to use to send messages for a		established, which tunnel or tunnels to use to send messages for a
	given conference is outside the scope of this document.		given conference is outside the scope of this document.
	5.3. Versioning Considerations		5.3. Media Distributor Tunneling Procedures
	All messages for an established tunnel MUST utilize the same version
	value. If the version of any subsequent message differs from that of
	the initial message, that message MUST be discarded and the tunnel
	connection closed.
	Since the media distributor sends the first message over the tunnel,
	it effectively establishes the version of the protocol to be used.
	If that version is not supported by the key distributor, it MUST
	discard the message, transmit an "UnsupportedVersion" message, and
	close the TLS connection.
	The media distributor MUST take note of the version received in an
	"UnsupportedVersion" message and use that version when attempting to
	re-establish a failed tunnel connection. Note that it is not
	necessary for the media distributor to understand the newer version
	of the protocol to understand that the first message received is
	"UnsupportedVersion". The media distributor can determine from the
	first two octets received what the version number is and that the
	message is "UnsupportedVersion". The rest of the data received, if
	any, would be discarded and the connection closed (if not already
	closed).
	5.4. Media Distributor Tunneling Procedures
	The first message transmitted over the tunnel is the		The first message transmitted over the tunnel is the
	"SupportedProfiles" (see Section 6). This message informs the key		"SupportedProfiles" (see Section 6). This message informs the key
	distributor about which DTLS-SRTP profiles the media distributor		distributor about which DTLS-SRTP profiles the media distributor
	supports. This message MUST be sent each time a new tunnel		supports. This message MUST be sent each time a new tunnel
	connection is established or, in the case of connection loss, when a		connection is established or, in the case of connection loss, when a
	connection is re-established.		connection is re-established. The media distributor MUST support the
			same list of protection profiles for the duration of any endpoint-
	The media distributor MUST forward all messages received from an		initiated DTLS association and tunnel connection.
	endpoint for a given DTLS association through the same tunnel if more
	than one tunnel has been established between it and a key
	distributor.
	Editor's Note: Do we want to have the above requirement or would
	we prefer to allow the media distributor to send messages over
	more than one tunnel to more than one key distributor? The latter
	would provide for higher availability, but at the cost of key
	distributor complexity. The former would allow the usage of a
	load distributor in front of the key distributor.
	The media distributor MUST assign a unique association identifier for		The media distributor MUST assign a unique association identifier for
	each endpoint-initiated DTLS association and include it in all		each endpoint-initiated DTLS association and include it in all
	messages forwarded to the key distributor. The key distributor will		messages forwarded to the key distributor. The key distributor will
	subsequently include this identifier in all messages it sends so that		subsequently include this identifier in all messages it sends so that
	the media distributor can map messages received via a tunnel and		the media distributor can map messages received via a tunnel and
	forward those messages to the correct endpoint. The association		forward those messages to the correct endpoint. The association
	identifier SHOULD be randomly assigned and values not be re-used for		identifier MUST be randomly assigned UUID [RFC4122] value.
	a short period of time (e.g., five minutes) to ensure any residual
	state in the key distributor is clear and to ensure any packets
	already transmitted from the key distributor are not directed to the
	wrong endpoint.
	The tunnel protocol enables the key distributor to separately provide
	HBH keying material to the media distributor for each of the
	individual endpoint DTLS associations, though the media distributor
	cannot decrypt messages between the key distributor and endpoints.
	When a DTLS message is received by the media distributor from an		When a DTLS message is received by the media distributor from an
	endpoint, it forwards the UDP payload portion of that message to the		endpoint, it forwards the UDP payload portion of that message to the
	key distributor encapsulated in a "TuneledDtls" message. If the		key distributor encapsulated in a "TuneledDtls" message. The media
	media distributor knows the conference to which a given DTLS		distributor is not required to forward all messages received from an
	association belongs, it can pass the conference identifier to the key		endpoint for a given DTLS association through the same tunnel if more
	distributor using the "conf_id" field of the "TunneledDtls" message.		than one tunnel has been established between it and a key
			distributor.
	Editor's Note: if the PERC WG adopts the "dtls-id" concept
	presented in [I-D.jones-tls-perc-dtls-id], we can remove "conf_id"
	from this draft, since the "dtls-id" can convey enough information
	for the key distributor to determine the correct conference.
	The media distributor MUST support the same list of protection
	profiles for the life of a given endpoint's DTLS association, which
	is represented by the association identifier.
	When a "MediaKeys" message is received, the media distributor MUST		When a "MediaKeys" message is received, the media distributor MUST
	extract the cipher and keying material conveyed in order to		extract the cipher and keying material conveyed in order to
	subsequently perform HBH encryption and authentication operations for		subsequently perform HBH encryption and authentication operations for
	RTP and RTCP packets sent between it and an endpoint. Since the HBH		RTP and RTCP packets sent between it and an endpoint. Since the HBH
	keying material will be different for each endpoint, the media		keying material will be different for each endpoint, the media
	distributor uses the association identifier included by the key		distributor uses the association identifier included by the key
	distributor to ensure that the HBH keying material is used with the		distributor to ensure that the HBH keying material is used with the
	correct endpoint.		correct endpoint.
	skipping to change at page 9, line 10 ¶		skipping to change at page 8, line 20 ¶
	when it receives conference control messages indicating the endpoint		when it receives conference control messages indicating the endpoint
	is to be disconnected, the media distributors MUST send an		is to be disconnected, the media distributors MUST send an
	"EndpointDisconnect" message with the association identifier assigned		"EndpointDisconnect" message with the association identifier assigned
	to the endpoint to the key distributor. The media distributor SHOULD		to the endpoint to the key distributor. The media distributor SHOULD
	take a loss of all RTP and RTCP packets as an indicator that the		take a loss of all RTP and RTCP packets as an indicator that the
	endpoint has disconnected. The particulars of how RTP and RTCP are		endpoint has disconnected. The particulars of how RTP and RTCP are
	to be used to detect an endpoint disconnect, such as timeout period,		to be used to detect an endpoint disconnect, such as timeout period,
	is not specified. The media distributor MAY use additional		is not specified. The media distributor MAY use additional
	indicators to determine when an endpoint has disconnected.		indicators to determine when an endpoint has disconnected.
	5.5. Key Distributor Tunneling Procedures		5.4. Key Distributor Tunneling Procedures
			Each TLS tunnel established between the media distributor and the key
			distributor MUST be mutually authenticated.
	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
			MUST extract the "tls_id" value transmitted in the "ClientHello"
			message and match that against "tls-id" value the endpoint
			transmitted via SDP. If the values in SDP and the "ClientHello" do
			not match, the DTLS association MUST be rejected.
			The process through which the "tls-id" in SDP is conveyed to the key
			distributor is outside the scope of this document.
			Editor's Note: The above can be removed if we agree that the media
			distributor will always forward SDP to the key distributor. That
			said, should the media server take on this function or should some
			other call control function do this? The former assumes the media
			distributor always has the SDP.
			The key distributor MUST correlate the certificate fingerprint and
			"tls_id" received from endpoint's "ClientHello" message with the
			corresponding values received from the SDP transmitted by the
			endpoint. It is through this correlation that the key distributor
			can be sure to deliver the correct conference key to the endpoint.
			When sending the "ServerHello" message, the key distributor MUST
			insert its own "tls_id" value in the "sdp_tls_id" extension. This
			value MUST also be conveyed back to the client via 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).		endpoint inside a "TunneledDtls" message (see Section 6). The key
			distributor is not required to transmit all messages a given DTLS
			association through the same tunnel if more than one tunnel has been
			established between it and a 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
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 37 ¶
	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 the HBH encryption key is computed and before
	it sends a DTLS "Finished" message to the endpoint. The "MediaKeys"		it sends a DTLS "Finished" message to the endpoint. The "MediaKeys"
	message includes the selected cipher (i.e. protection profile), MKI		message includes the selected cipher (i.e. protection profile), MKI
	[RFC3711] value (if any), SRTP master keys, and SRTP master salt		[RFC3711] value (if any), SRTP master keys, and SRTP master salt
	values. The key distributor MUST use the same association identifier		values. The key distributor MUST use the same association identifier
	in the "MediaKeys" message as is used in the "TunneledDtls" messages		in the "MediaKeys" message as is used in the "TunneledDtls" messages
	for the given endpoint.		for the given endpoint.
	The key distributor, can use the certificate of the endpoint and		The key distributor uses the certificate fingerprint of the endpoint
	correlate that with signaling information to know which conference		along with the "tls_id" value received in the "sdp_tls_id" extension
	this session is associated with. The key distributor informs the		to determine which conference a given DTLS association is associated.
	media distributor of which conference this session is associated by
	sending a globally unique conference identifier in the "conf_id"
	attribute of the "MediaKeys".
	The key distributor MUST select a cipher that is supported by both		The key distributor MUST select a cipher that is supported by both
	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
			distributor is terminated, regardless of which entity initiated the
			termination, the key distributor MUST send an "EndpointDisconnect"
			message with the association identifier assigned to the endpoint to
			the media distributor.
			5.5. Versioning Considerations
			All messages for an established tunnel MUST utilize the same version
			value.
			Since the media distributor sends the first message over the tunnel,
			it effectively establishes the version of the protocol to be used.
			If that version is not supported by the key distributor, it MUST
			discard the message, transmit an "UnsupportedVersion" message, and
			close the TLS connection.
			The media distributor MUST take note of the version received in an
			"UnsupportedVersion" message and use that version when attempting to
			re-establish a failed tunnel connection. Note that it is not
			necessary for the media distributor to understand the newer version
			of the protocol to understand that the first message received is
			"UnsupportedVersion". The media distributor can determine from the
			first two octets received what the version number is and that the
			message is "UnsupportedVersion". The rest of the data received, if
			any, would be discarded and the connection closed (if not already
			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 [RFC5246]
	section 4. As in [RFC5246], all values are stored in network byte		section 4. As in [RFC5246], 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.
	The protocol defines several different messages, each of which		The protocol defines several different messages, each of which
	skipping to change at page 11, line 6 ¶		skipping to change at page 11, line 6 ¶
	message type indicating the actual content of the message body.		message type indicating the actual content of the message body.
	6.1. Tunnel Message Format		6.1. Tunnel Message Format
	The syntax of the protocol is defined below. "TunnelMessage" defines		The syntax of the protocol is defined below. "TunnelMessage" defines
	the structure of all messages sent via the tunnel protocol. That		the structure of all messages sent via the tunnel protocol. That
	structure includes a field called "msg_type" that identifies the		structure includes a field called "msg_type" that identifies the
	specific type of message contained within "TunnelMessage".		specific type of message contained within "TunnelMessage".
	enum {		enum {
	unsupported_version(1),		supported_profiles(1),
	supported_profiles(2),		unsupported_version(2),
	media_keys(3),		media_keys(3),
	tunneled_dtls(4),		tunneled_dtls(4),
	endpoint_disconnect(5),		endpoint_disconnect(5),
	(255)		(255)
	} MsgType;		} MsgType;
			opaque uuid[16];
	struct {		struct {
	uint8 version;
	MsgType msg_type;		MsgType msg_type;
			uint16 length;
	select (MsgType) {		select (MsgType) {
	case unsupported_version: UnsupportedVersion;
	case supported_profiles: SupportedProfiles;		case supported_profiles: SupportedProfiles;
			case unsupported_version: UnsupportedVersion;
	case media_keys: MediaKeys;		case media_keys: MediaKeys;
	case tunneled_dtls: TunneledDtls;		case tunneled_dtls: TunneledDtls;
	case endpoint_disconnect: EndpointDisconnect;		case endpoint_disconnect: EndpointDisconnect;
	} body;		} body;
	} TunnelMessage;		} TunnelMessage;
	The elements of "TunnelMessage" include:		The elements of "TunnelMessage" include:
	o version: indicates the version of this protocol (0x00).
	o msg_type: the type of message contained within the structure		o msg_type: the type of message contained within the structure
	"body".		"body".
			o length: the length in octets of the following "body" of the
	The "UnsupportedVersion" message is defined as follows:		message.
	struct { } UnsupportedVersion;
	The "UnsupportedVersion" message does not convey any additional
	information in the body.
	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;
	SRTPProtectionProfile protection_profiles<0..2^16-1>;		SRTPProtectionProfile protection_profiles<0..2^16-1>;
	} SupportedProfiles;		} SupportedProfiles;
	This message contains this single element: * protection_profiles: The		This message contains this single element:
	list of two-octet SRTP protection profile values as per [RFC5764]
	supported by the media distributor.		o version: indicates the version of this protocol (0x00).
			o protection_profiles: The list of two-octet SRTP protection profile
			values as per [RFC5764] supported by the media distributor.
			The "UnsupportedVersion" message is defined as follows:
			struct {
			uint8 highest_version;
			} UnsupportedVersion;
			The elements of "UnsupportedVersion" include:
			o highest_version: indicates the highest supported protocol version.
	The "MediaKeys" message is defined as:		The "MediaKeys" message is defined as:
	struct {		struct {
	uint32 association_id;		uuid association_id;
	SRTPProtectionProfile protection_profile;		SRTPProtectionProfile protection_profile;
	opaque mki<0..255>;		opaque mki<0..255>;
	opaque client_write_SRTP_master_key<1..255>;		opaque client_write_SRTP_master_key<1..255>;
	opaque server_write_SRTP_master_key<1..255>;		opaque server_write_SRTP_master_key<1..255>;
	opaque client_write_SRTP_master_salt<1..255>;		opaque client_write_SRTP_master_salt<1..255>;
	opaque server_write_SRTP_master_salt<1..255>;		opaque server_write_SRTP_master_salt<1..255>;
	opaque conf_id<0..255>;
	} MediaKeys;		} MediaKeys;
	The fields are described as follows:		The fields are described as follows:
	o association_id: A value that identifies a distinct DTLS		o association_id: A value that identifies a distinct DTLS
	association between an endpoint and the key distributor.		association between an endpoint and the key distributor.
	o protection_profiles: The value of the two-octet SRTP protection		o protection_profiles: The value of the two-octet SRTP protection
	profile value as per [RFC5764] used for this DTLS association.		profile value as per [RFC5764] used for this DTLS association.
	o mki: Master key identifier [RFC3711].		o mki: Master key identifier [RFC3711].
	o client_write_SRTP_master_key: The value of the SRTP master key		o client_write_SRTP_master_key: The value of the SRTP master key
	used by the client (endpoint).		used by the client (endpoint).
	o server_write_SRTP_master_key: The value of the SRTP master key		o server_write_SRTP_master_key: The value of the SRTP master key
	used by the server (media distributor).		used by the server (media distributor).
	o client_write_SRTP_master_salt: The value of the SRTP master salt		o client_write_SRTP_master_salt: The value of the SRTP master salt
	used by the client (endpoint).		used by the client (endpoint).
	o server_write_SRTP_master_salt: The value of the SRTP master salt		o server_write_SRTP_master_salt: The value of the SRTP master salt
	used by the server (media distributor).		used by the server (media distributor).
	o conf_id: Identifier that uniquely specifies which conference the
	media distributor should place this media flow in.
	The "TunneledDtls" message is defined as:		The "TunneledDtls" message is defined as:
	struct {		struct {
	uint32 association_id;		uuid association_id;
	opaque conf_id<0..255>;
	opaque dtls_message<0..2^16-1>;		opaque dtls_message<0..2^16-1>;
	} TunneledDtls;		} TunneledDtls;
	The fields are described as follows:		The fields are described as follows:
	o association_id: An value that identifies a distinct DTLS		o 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.
	o conf_id: Optional identifier that uniquely specifies which
	conference this media flow is in.
	o dtls_message: the content of the DTLS message received by the		o dtls_message: the content of the DTLS message received by the
	endpoint or to be sent to the endpoint.		endpoint or to be sent to the endpoint.
	The "EndpointDisconect" message is defined as:		The "EndpointDisconect" message is defined as:
	struct {		struct {
	uint32 association_id;		uuid association_id;
	} EndpointDisconnect;		} EndpointDisconnect;
	The fields are described as follows:		The fields are described as follows:
	o association_id: An value that identifies a distinct DTLS		o 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		specified in [RFC5246]. This section provides an example of what the
	the bits on the wire would look like for the "SupportedProfiles"		bits on the wire would look like for the "SupportedProfiles" message
	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 [I-D.ietf-perc-double].		DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [I-D.ietf-perc-double].
	RFC Editor Note: Please replace the values 0009 and 000A in the		RFC Editor Note: Please replace the values 0009 and 000A in the
	following two examples with whatever code points IANA assigned for		following two examples with whatever code points IANA assigned for
	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.		DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM.
	TunnelMessage:		TunnelMessage:
	version: 0x00
	message_type: 0x01		message_type: 0x01
			length: 0x0007
	SupportedProfiles:		SupportedProfiles:
			version: 0x00
	protection_profiles: 0x0004 (length)		protection_profiles: 0x0004 (length)
	0x0009000A (value)		0x0009000A (value)
	Thus, the encoding on the wire presented here in network bytes order		Thus, the encoding on the wire presented here in network bytes order
	would be this stream of octets:		would be this stream of octets:
	0x000100040009000A		0x0100070000040009000A
	8. IANA Considerations		8. IANA Considerations
	This document establishes a new registry to contain message type		This document establishes a new registry to contain message type
	values used in the DTLS Tunnel protocol. These data type values are		values used in the DTLS Tunnel protocol. These data type values are
	a single octet in length. This document defines the values shown in		a single octet in length. This document defines the values shown in
	Table 1 below, leaving the balance of possible values reserved for		Table 1 below, leaving the balance of possible values reserved for
	future specifications:		future specifications:
	+---------+------------------------------------+		+---------+------------------------------------+
	| MsgType | Description |		| MsgType | Description |
	+---------+------------------------------------+		+---------+------------------------------------+
	| 0x01 | Unsupported Version |		| 0x01 | Supported SRTP Protection Profiles |
	| 0x02 | Supported SRTP Protection Profiles |		| 0x02 | Unsupported Version |
	| 0x03 | Media Keys |		| 0x03 | Media Keys |
	| 0x04 | Tunneled DTLS |		| 0x04 | Tunneled DTLS |
	| 0x05 | Endpoint Disconnect |		| 0x05 | Endpoint Disconnect |
	+---------+------------------------------------+		+---------+------------------------------------+
	Table 1: Data Type Values for the DTLS Tunnel Protocol		Table 1: Data Type Values for the DTLS Tunnel Protocol
	The value 0x00 and all values in the range 0x06 to 0xFF are reserved.		The value 0x00 and all values in the range 0x06 to 0xFF are reserved.
	The name for this registry is "Datagram Transport Layer Security		The name for this registry is "Datagram Transport Layer Security
	skipping to change at page 15, line 6 ¶		skipping to change at page 15, line 6 ¶
	media distributor and the key distributor.		media distributor and the 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. References		11. References
	11.1. Normative References		11.1. Normative References
			[I-D.ietf-mmusic-dtls-sdp]
			Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer
			Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-24 (work
			in progress), April 2017.
			[I-D.thomson-mmusic-sdp-uks]
			Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
			uses of Transport Layer Security with the Session
			Description Protocol (SDP)", draft-thomson-mmusic-sdp-
			uks-00 (work in progress), April 2017.
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
			[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
			with Session Description Protocol (SDP)", RFC 3264,
			DOI 10.17487/RFC3264, June 2002,
			<http://www.rfc-editor.org/info/rfc3264>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <http://www.rfc-editor.org/info/rfc3550>.		July 2003, <http://www.rfc-editor.org/info/rfc3550>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<http://www.rfc-editor.org/info/rfc3711>.		<http://www.rfc-editor.org/info/rfc3711>.
			[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
			Unique IDentifier (UUID) URN Namespace", RFC 4122,
			DOI 10.17487/RFC4122, July 2005,
			<http://www.rfc-editor.org/info/rfc4122>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/		(TLS) Protocol Version 1.2", RFC 5246,
	RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	[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, DOI		Real-time Transport Protocol (SRTP)", RFC 5764,
	10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010,
	<http://www.rfc-editor.org/info/rfc5764>.		<http://www.rfc-editor.org/info/rfc5764>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <http://www.rfc-editor.org/info/rfc6347>.		January 2012, <http://www.rfc-editor.org/info/rfc6347>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-perc-double]		[I-D.ietf-perc-double]
	Jennings, C., Jones, P., and A. Roach, "SRTP Double		Jennings, C., Jones, P., and A. Roach, "SRTP Double
	Encryption Procedures", draft-ietf-perc-double-02 (work in		Encryption Procedures", draft-ietf-perc-double-03 (work in
	progress), October 2016.		progress), March 2017.
	[I-D.jones-tls-perc-dtls-id]		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Jones, P. and N. Ohlmeier, "Transporting the SDP attribute		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
	'dtls-id' in TLS and DTLS", March 2017.		July 2006, <http://www.rfc-editor.org/info/rfc4566>.
	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
	USA		USA
	Phone: +1 919 476 2048		Phone: +1 919 476 2048
	Email: paulej@packetizer.com		Email: paulej@packetizer.com
	Paul M. Ellenbogen		Paul M. Ellenbogen
End of changes. 47 change blocks.
	120 lines changed or deleted		166 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/