idnits 2.17.1 draft-ietf-perc-dtls-tunnel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2017) is 2602 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 485 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-02 -- No information found for draft-jones-tls-perc-dtls-id - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track P. Ellenbogen 5 Expires: September 13, 2017 Princeton University 6 N. Ohlmeier 7 Mozilla 8 March 12, 2017 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-ietf-perc-dtls-tunnel-00 14 Abstract 16 This document defines a DTLS tunneling protocol for use in multimedia 17 conferences that enables a Media Distributor to facilitate key 18 exchange between an endpoint in a conference and the Key Distributor. 19 The protocol is designed to ensure that the keying material used for 20 hop-by-hop encryption and authentication is accessible to the media 21 distributor, while the keying material used for end-to-end encryption 22 and authentication is inaccessible to the media distributor. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 60 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 62 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 64 5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 65 5.3. Versioning Considerations . . . . . . . . . . . . . . . . 7 66 5.4. Media Distributor Tunneling Procedures . . . . . . . . . 7 67 5.5. Key Distributor Tunneling Procedures . . . . . . . . . . 9 68 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10 70 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 11.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 An objective of Privacy-Enhanced RTP Conferencing (PERC) is to ensure 82 that endpoints in a multimedia conference have access to the end-to- 83 end (E2E) and hop-by-hop (HBH) keying material used to encrypt and 84 authenticate Real-time Transport Protocol (RTP) [RFC3550] packets, 85 while the Media Distributor has access only to the hop-by-hop (HBH) 86 keying material for encryption and authentication. 88 This specification defines a tunneling protocol that enables the 89 media distributor to tunnel DTLS [RFC6347] messages between an 90 endpoint and the key distributor, thus allowing an endpoint to use 91 DTLS-SRTP [RFC5764] for establishing encryption and authentication 92 keys with the key distributor. 94 The tunnel established between the media distributor and key 95 distributor is a TLS connection that is established before any 96 messages are forwarded by the media distributor on behalf of the 97 endpoint. DTLS packets received from the endpoint are encapsulated 98 by the media distributor inside this tunnel as data to be sent to the 99 key distributor. Likewise, when the media distributor receives data 100 from the key distributor over the tunnel, it extracts the DTLS 101 message inside and forwards the DTLS message to the endpoint. In 102 this way, the DTLS association for the DTLS-SRTP procedures is 103 established between the endpoint and the key distributor, with the 104 media distributor simply forwarding packets between the two entities 105 and having no visibility into the confidential information exchanged. 107 Following the existing DTLS-SRTP procedures, the endpoint and key 108 distributor will arrive at a selected cipher and keying material, 109 which are used for HBH encryption and authentication by both the 110 endpoint and the media distributor. However, since the media 111 distributor would not have direct access to this information, the key 112 distributor explicitly shares the HBH key information with the media 113 distributor via the tunneling protocol defined in this document. 114 Additionally, the endpoint and key distributor will agree on a cipher 115 for E2E encryption and authentication. The key distributor will 116 transmit keying material to the endpoint for E2E operations, but will 117 not share that information with the media distributor. 119 By establishing this TLS tunnel between the media distributor and key 120 distributor and implementing the protocol defined in this document, 121 it is possible for the media distributor to facilitate the 122 establishment of a secure DTLS association between an endpoint and 123 the key distributor in order for the endpoint to receive E2E and HBH 124 keying material. At the same time, the key distributor can securely 125 provide the HBH keying material to the media distributor. 127 2. Conventions Used In This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119] when they 132 appear in ALL CAPS. These words may also appear in this document in 133 lower case as plain English words, absent their normative meanings. 135 3. Tunneling Concept 137 A TLS connection (tunnel) is established between the media 138 distributor and the key distributor. This tunnel is used to relay 139 DTLS messages between the endpoint and key distributor, as depicted 140 in Figure 1: 142 +-------------+ 143 | Key | 144 | Distributor | 145 +-------------+ 146 # ^ ^ # 147 # | | # <-- TLS Tunnel 148 # | | # 149 +----------+ +-------------+ +----------+ 150 | | DTLS | | DTLS | | 151 | Endpoint |<------------| Media |------------>| Endpoint | 152 | | to Key | Distributor | to Key | | 153 | | Distributor | | Distributor | | 154 +----------+ +-------------+ +----------+ 156 Figure 1: TLS Tunnel to Key Distributor 158 The three entities involved in this communication flow are the 159 endpoint, the media distributor, and the key distributor. The 160 behavior of each entity is described in Section 5. 162 The key distributor is a logical function that might might be co- 163 resident with a key management server operated by an enterprise, 164 reside in one of the endpoints participating in the conference, or 165 elsewhere that is trusted with E2E keying material. 167 4. Example Message Flows 169 This section provides an example message flow to help clarify the 170 procedures described later in this document. It is necessary that 171 the key distributor and media distributor establish a mutually 172 authenticated TLS connection for the purpose of sending tunneled 173 messages, though the complete TLS handshake for the tunnel is not 174 shown in Figure 2 since there is nothing new this document introduces 175 with regard to those procedures. 177 Once the tunnel is established, it is possible for the media 178 distributor to relay the DTLS messages between the endpoint and the 179 key distributor. Figure 2 shows a message flow wherein the endpoint 180 uses DTLS-SRTP to establish an association with the key distributor. 181 In the process, the media distributor shares its supported SRTP 182 protection profile information (see [RFC5764]) and the key 183 distributor shares HBH keying material and selected cipher with the 184 media distributor. 186 Endpoint media distributor key distributor 187 | | | 188 | |<=======================>| 189 | | TLS Connection Made | 190 | | | 191 | |========================>| 192 | | SupportedProfiles | 193 | | | 194 |------------------------>|========================>| 195 | DTLS handshake message | TunneledDtls | 196 | | | 197 | |<========================| 198 | | MediaKeys | 199 | | | 200 .... may be multiple handshake messages ... 201 | | | 202 |<------------------------|<========================| 203 | DTLS handshake message | TunneledDtls | 204 | | | 206 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 208 After the initial TLS connection has been established each of the 209 messages on the right-hand side of Figure 2 is a tunneling protocol 210 message as defined in Section Section 6. 212 SRTP protection profiles supported by the media distributor will be 213 sent in a "SupportedProfiles" message when the TLS tunnel is 214 initially established. The key distributor will use that information 215 to select a common profile supported by both the endpoint and the 216 media distributor to ensure that hop-by-hop operations can be 217 successfully performed. 219 As DTLS messages are received from the endpoint by the media 220 distributor, they are forwarded to the key distributor encapsulated 221 inside abbrev "TunneledDtls" message. Likewise, as "TunneledDtls" 222 messages are received by the media distributor from the key 223 distributor, the encapsulated DTLS packet is forwarded to the 224 endpoint. 226 The key distributor will provide the SRTP [RFC3711] keying material 227 to the media distributor for HBH operations via the "MediaKeys" 228 message. The media distributor will extract this keying material 229 from the "MediaKeys" message when received and use it for hop-by-hop 230 encryption and authentication. 232 5. Tunneling Procedures 234 The following sub-sections explain in detail the expected behavior of 235 the endpoint, the media distributor, and the key distributor. 237 It is important to note that the tunneling protocol described in this 238 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 239 Rather, it is a protocol that transports DTLS messages generated by 240 an endpoint or key distributor as data inside of the TLS connection 241 established between the media distributor and key distributor. 243 5.1. Endpoint Procedures 245 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 246 in order to establish the cipher and keys used for encryption and 247 authentication, with the endpoint acting as the client and the key 248 distributor acting as the server. The endpoint does not need to be 249 aware of the fact that DTLS messages it transmits toward the media 250 distributor are being tunneled to the key distributor. 252 5.2. Tunnel Establishment Procedures 254 Either the media distributor or key distributor initiates the 255 establishment of a TLS tunnel. Which entity acts as the TLS client 256 when establishing the tunnel and what event triggers the 257 establishment of the tunnel are outside the scope of this document. 258 Further, how the trust relationships are established between the key 259 distributor and media distributor are also outside the scope of this 260 document. 262 A tunnel MUST be a mutually authenticated TLS connection. 264 The media distributor or key distributor MUST establish a tunnel 265 prior to forwarding tunneled DTLS messages. Given the time-sensitive 266 nature of DTLS-SRTP procedures, a tunnel SHOULD be established prior 267 to the media distributor receiving a DTLS message from an endpoint. 269 A single tunnel MAY be used to relay DTLS messages between any number 270 of endpoints and the key distributor. 272 A media distributor MAY have more than one tunnel established between 273 itself and one or more key distributors. When multiple tunnels are 274 established, which tunnel or tunnels to use to send messages for a 275 given conference is outside the scope of this document. 277 5.3. Versioning Considerations 279 All messages for an established tunnel MUST utilize the same version 280 value. If the version of any subsequent message differs from that of 281 the initial message, that message MUST be discarded and the tunnel 282 connection closed. 284 Since the media distributor sends the first message over the tunnel, 285 it effectively establishes the version of the protocol to be used. 286 If that version is not supported by the key distributor, it MUST 287 discard the message, transmit an "UnsupportedVersion" message, and 288 close the TLS connection. 290 The media distributor MUST take note of the version received in an 291 "UnsupportedVersion" message and use that version when attempting to 292 re-establish a failed tunnel connection. Note that it is not 293 necessary for the media distributor to understand the newer version 294 of the protocol to understand that the first message received is 295 "UnsupportedVersion". The media distributor can determine from the 296 first two octets received what the version number is and that the 297 message is "UnsupportedVersion". The rest of the data received, if 298 any, would be discarded and the connection closed (if not already 299 closed). 301 5.4. Media Distributor Tunneling Procedures 303 The first message transmitted over the tunnel is the 304 "SupportedProfiles" (see Section 6). This message informs the key 305 distributor about which DTLS-SRTP profiles the media distributor 306 supports. This message MUST be sent each time a new tunnel 307 connection is established or, in the case of connection loss, when a 308 connection is re-established. 310 The media distributor MUST forward all messages received from an 311 endpoint for a given DTLS association through the same tunnel if more 312 than one tunnel has been established between it and a key 313 distributor. 315 Editor's Note: Do we want to have the above requirement or would 316 we prefer to allow the media distributor to send messages over 317 more than one tunnel to more than one key distributor? The latter 318 would provide for higher availability, but at the cost of key 319 distributor complexity. The former would allow the usage of a 320 load distributor in front of the key distributor. 322 The media distributor MUST assign a unique association identifier for 323 each endpoint-initiated DTLS association and include it in all 324 messages forwarded to the key distributor. The key distributor will 325 subsequently include this identifier in all messages it sends so that 326 the media distributor can map messages received via a tunnel and 327 forward those messages to the correct endpoint. The association 328 identifier SHOULD be randomly assigned and values not be re-used for 329 a short period of time (e.g., five minutes) to ensure any residual 330 state in the key distributor is clear and to ensure any packets 331 already transmitted from the key distributor are not directed to the 332 wrong endpoint. 334 The tunnel protocol enables the key distributor to separately provide 335 HBH keying material to the media distributor for each of the 336 individual endpoint DTLS associations, though the media distributor 337 cannot decrypt messages between the key distributor and endpoints. 339 When a DTLS message is received by the media distributor from an 340 endpoint, it forwards the UDP payload portion of that message to the 341 key distributor encapsulated in a "TuneledDtls" message. If the 342 media distributor knows the conference to which a given DTLS 343 association belongs, it can pass the conference identifier to the key 344 distributor using the "conf_id" field of the "TunneledDtls" message. 346 Editor's Note: if the PERC WG adopts the "dtls-id" concept 347 presented in [I-D.jones-tls-perc-dtls-id], we can remove "conf_id" 348 from this draft, since the "dtls-id" can convey enough information 349 for the key distributor to determine the correct conference. 351 The media distributor MUST support the same list of protection 352 profiles for the life of a given endpoint's DTLS association, which 353 is represented by the association identifier. 355 When a "MediaKeys" message is received, the media distributor MUST 356 extract the cipher and keying material conveyed in order to 357 subsequently perform HBH encryption and authentication operations for 358 RTP and RTCP packets sent between it and an endpoint. Since the HBH 359 keying material will be different for each endpoint, the media 360 distributor uses the association identifier included by the key 361 distributor to ensure that the HBH keying material is used with the 362 correct endpoint. 364 The media distributor MUST forward all DTLS messages received from 365 either the endpoint or the key distributor (via the "TunneledDtls" 366 message) to ensure proper communication between those two entities. 368 When the media distributor detects an endpoint has disconnected or 369 when it receives conference control messages indicating the endpoint 370 is to be disconnected, the media distributors MUST send an 371 "EndpointDisconnect" message with the association identifier assigned 372 to the endpoint to the key distributor. The media distributor SHOULD 373 take a loss of all RTP and RTCP packets as an indicator that the 374 endpoint has disconnected. The particulars of how RTP and RTCP are 375 to be used to detect an endpoint disconnect, such as timeout period, 376 is not specified. The media distributor MAY use additional 377 indicators to determine when an endpoint has disconnected. 379 5.5. Key Distributor Tunneling Procedures 381 When the media distributor relays a DTLS message from an endpoint, 382 the media distributor will include an association identifier that is 383 unique per endpoint-originated DTLS association. The association 384 identifier remains constant for the life of the DTLS association. 385 The key distributor identifies each distinct endpoint-originated DTLS 386 association by the association identifier. 388 The key distributor MUST encapsulate any DTLS message it sends to an 389 endpoint inside a "TunneledDtls" message (see Section 6). 391 The key distributor MUST use the same association identifier in 392 messages sent to an endpoint as was received in messages from that 393 endpoint. This ensures the media distributor can forward the 394 messages to the correct endpoint. 396 The key distributor extracts tunneled DTLS messages from an endpoint 397 and acts on those messages as if that endpoint had established the 398 DTLS association directly with the key distributor. The key 399 distributor is acting as the DTLS server and the endpoint is acting 400 as the DTLS client. The handling of the messages and certificates is 401 exactly the same as normal DTLS-SRTP procedures between endpoints. 403 The key distributor MUST send a "MediaKeys" message to the media 404 distributor as soon as the HBH encryption key is computed and before 405 it sends a DTLS "Finished" message to the endpoint. The "MediaKeys" 406 message includes the selected cipher (i.e. protection profile), MKI 407 [RFC3711] value (if any), SRTP master keys, and SRTP master salt 408 values. The key distributor MUST use the same association identifier 409 in the "MediaKeys" message as is used in the "TunneledDtls" messages 410 for the given endpoint. 412 The key distributor, can use the certificate of the endpoint and 413 correlate that with signaling information to know which conference 414 this session is associated with. The key distributor informs the 415 media distributor of which conference this session is associated by 416 sending a globally unique conference identifier in the "conf_id" 417 attribute of the "MediaKeys". 419 The key distributor MUST select a cipher that is supported by both 420 the endpoint and the media distributor to ensure proper HBH 421 operations. 423 6. Tunneling Protocol 425 Tunneled messages are transported via the TLS tunnel as application 426 data between the media distributor and the key distributor. Tunnel 427 messages are specified using the format described in [RFC5246] 428 section 4. As in [RFC5246], all values are stored in network byte 429 (big endian) order; the uint32 represented by the hex bytes 01 02 03 430 04 is equivalent to the decimal value 16909060. 432 The protocol defines several different messages, each of which 433 containing the the following information: 435 o Protocol version 436 o Message type identifier 437 o The message body 439 Each of these messages is a "TunnelMessage" in the syntax, with a 440 message type indicating the actual content of the message body. 442 6.1. Tunnel Message Format 444 The syntax of the protocol is defined below. "TunnelMessage" defines 445 the structure of all messages sent via the tunnel protocol. That 446 structure includes a field called "msg_type" that identifies the 447 specific type of message contained within "TunnelMessage". 449 enum { 450 unsupported_version(1), 451 supported_profiles(2), 452 media_keys(3), 453 tunneled_dtls(4), 454 endpoint_disconnect(5), 455 (255) 456 } MsgType; 458 struct { 459 uint8 version; 460 MsgType msg_type; 461 select (MsgType) { 462 case unsupported_version: UnsupportedVersion; 463 case supported_profiles: SupportedProfiles; 464 case media_keys: MediaKeys; 465 case tunneled_dtls: TunneledDtls; 466 case endpoint_disconnect: EndpointDisconnect; 467 } body; 468 } TunnelMessage; 470 The elements of "TunnelMessage" include: 472 o version: indicates the version of this protocol (0x00). 473 o msg_type: the type of message contained within the structure 474 "body". 476 The "UnsupportedVersion" message is defined as follows: 478 struct { } UnsupportedVersion; 480 The "UnsupportedVersion" message does not convey any additional 481 information in the body. 483 The "SupportedProfiles" message is defined as: 485 uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ 487 struct { 488 SRTPProtectionProfile protection_profiles<0..2^16-1>; 489 } SupportedProfiles; 491 This message contains this single element: * protection_profiles: The 492 list of two-octet SRTP protection profile values as per [RFC5764] 493 supported by the media distributor. 495 The "MediaKeys" message is defined as: 497 struct { 498 uint32 association_id; 499 SRTPProtectionProfile protection_profile; 500 opaque mki<0..255>; 501 opaque client_write_SRTP_master_key<1..255>; 502 opaque server_write_SRTP_master_key<1..255>; 503 opaque client_write_SRTP_master_salt<1..255>; 504 opaque server_write_SRTP_master_salt<1..255>; 505 opaque conf_id<0..255>; 506 } MediaKeys; 508 The fields are described as follows: 510 o association_id: A value that identifies a distinct DTLS 511 association between an endpoint and the key distributor. 512 o protection_profiles: The value of the two-octet SRTP protection 513 profile value as per [RFC5764] used for this DTLS association. 514 o mki: Master key identifier [RFC3711]. 515 o client_write_SRTP_master_key: The value of the SRTP master key 516 used by the client (endpoint). 517 o server_write_SRTP_master_key: The value of the SRTP master key 518 used by the server (media distributor). 519 o client_write_SRTP_master_salt: The value of the SRTP master salt 520 used by the client (endpoint). 521 o server_write_SRTP_master_salt: The value of the SRTP master salt 522 used by the server (media distributor). 523 o conf_id: Identifier that uniquely specifies which conference the 524 media distributor should place this media flow in. 526 The "TunneledDtls" message is defined as: 528 struct { 529 uint32 association_id; 530 opaque conf_id<0..255>; 531 opaque dtls_message<0..2^16-1>; 532 } TunneledDtls; 534 The fields are described as follows: 536 o association_id: An value that identifies a distinct DTLS 537 association between an endpoint and the key distributor. 538 o conf_id: Optional identifier that uniquely specifies which 539 conference this media flow is in. 540 o dtls_message: the content of the DTLS message received by the 541 endpoint or to be sent to the endpoint. 543 The "EndpointDisconect" message is defined as: 545 struct { 546 uint32 association_id; 547 } EndpointDisconnect; 549 The fields are described as follows: 551 o association_id: An value that identifies a distinct DTLS 552 association between an endpoint and the key distributor. 554 7. Example Binary Encoding 556 The "TunnelMessage" is encoded in binary following the procedures 557 specified in [![RFC5246]]. This section provides an example of what 558 the bits on the wire would look like for the "SupportedProfiles" 559 message that advertises support for both 560 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 561 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [I-D.ietf-perc-double]. 563 RFC Editor Note: Please replace the values 0009 and 000A in the 564 following two examples with whatever code points IANA assigned for 565 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 566 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. 568 TunnelMessage: 569 version: 0x00 570 message_type: 0x01 571 SupportedProfiles: 572 protection_profiles: 0x0004 (length) 573 0x0009000A (value) 575 Thus, the encoding on the wire presented here in network bytes order 576 would be this stream of octets: 578 0x000100040009000A 580 8. IANA Considerations 582 This document establishes a new registry to contain message type 583 values used in the DTLS Tunnel protocol. These data type values are 584 a single octet in length. This document defines the values shown in 585 Table 1 below, leaving the balance of possible values reserved for 586 future specifications: 588 +---------+------------------------------------+ 589 | MsgType | Description | 590 +---------+------------------------------------+ 591 | 0x01 | Unsupported Version | 592 | 0x02 | Supported SRTP Protection Profiles | 593 | 0x03 | Media Keys | 594 | 0x04 | Tunneled DTLS | 595 | 0x05 | Endpoint Disconnect | 596 +---------+------------------------------------+ 598 Table 1: Data Type Values for the DTLS Tunnel Protocol 600 The value 0x00 and all values in the range 0x06 to 0xFF are reserved. 602 The name for this registry is "Datagram Transport Layer Security 603 (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing". 605 9. Security Considerations 607 The encapsulated data is protected by the TLS connection from the 608 endpoint to key distributor, and the media distributor is merely an 609 on path entity. The media distributor does not have access to the 610 end-to-end keying material This does not introduce any additional 611 security concerns beyond a normal DTLS-SRTP association. 613 The HBH keying material is protected by the mutual authenticated TLS 614 connection between the media distributor and key distributor. The 615 key distributor MUST ensure that it only forms associations with 616 authorized media distributors or it could hand HBH keying material to 617 untrusted parties. 619 The supported profiles information sent from the media distributor to 620 the key distributor is not particularly sensitive as it only provides 621 the cryptographic algorithms supported by the media distributor. 622 Further, it is still protected by the TLS connection between the 623 media distributor and the key distributor. 625 10. Acknowledgments 627 The author would like to thank David Benham and Cullen Jennings for 628 reviewing this document and providing constructive comments. 630 11. References 631 11.1. Normative References 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 635 RFC2119, March 1997, 636 . 638 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 639 Jacobson, "RTP: A Transport Protocol for Real-Time 640 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 641 July 2003, . 643 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 644 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 645 RFC 3711, DOI 10.17487/RFC3711, March 2004, 646 . 648 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 649 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 650 RFC5246, August 2008, 651 . 653 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 654 Security (DTLS) Extension to Establish Keys for the Secure 655 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 656 10.17487/RFC5764, May 2010, 657 . 659 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 660 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 661 January 2012, . 663 11.2. Informative References 665 [I-D.ietf-perc-double] 666 Jennings, C., Jones, P., and A. Roach, "SRTP Double 667 Encryption Procedures", draft-ietf-perc-double-02 (work in 668 progress), October 2016. 670 [I-D.jones-tls-perc-dtls-id] 671 Jones, P. and N. Ohlmeier, "Transporting the SDP attribute 672 'dtls-id' in TLS and DTLS", March 2017. 674 Authors' Addresses 675 Paul E. Jones 676 Cisco Systems, Inc. 677 7025 Kit Creek Rd. 678 Research Triangle Park, North Carolina 27709 679 USA 681 Phone: +1 919 476 2048 682 Email: paulej@packetizer.com 684 Paul M. Ellenbogen 685 Princeton University 687 Phone: +1 206 851 2069 688 Email: pe5@cs.princeton.edu 690 Nils H. Ohlmeier 691 Mozilla 693 Phone: +1 408 659 6457 694 Email: nils@ohlmeier.org