idnits 2.17.1 draft-ietf-perc-dtls-tunnel-08.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 (20 May 2021) is 1062 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: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '16' on line 473 -- Looks like a reference, but probably isn't: '2' on line 497 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: Informational P. Ellenbogen 5 Expires: 21 November 2021 Princeton University 6 N. Ohlmeier 7 Mozilla 8 20 May 2021 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-ietf-perc-dtls-tunnel-08 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 https://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 21 November 2021. 41 Copyright Notice 43 Copyright (c) 2021 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 59 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 61 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 63 5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 64 5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7 65 5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 66 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10 67 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 11 69 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 74 12. Informative References . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is 80 to ensure that endpoints in a multimedia conference have access to 81 the end-to-end (E2E) and hop-by-hop (HBH) keying material used to 82 encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] 83 packets, while the Media Distributor has access only to the HBH 84 keying material for encryption and authentication. 86 This specification defines a tunneling protocol that enables the 87 media distributor to tunnel DTLS [RFC6347] messages between an 88 endpoint and the key distributor, thus allowing an endpoint to use 89 DTLS-SRTP [RFC5764] for establishing encryption and authentication 90 keys with the key distributor. 92 The tunnel established between the media distributor and key 93 distributor is a TLS connection that is established before any 94 messages are forwarded by the media distributor on behalf of the 95 endpoint. DTLS packets received from the endpoint are encapsulated 96 by the media distributor inside this tunnel as data to be sent to the 97 key distributor. Likewise, when the media distributor receives data 98 from the key distributor over the tunnel, it extracts the DTLS 99 message inside and forwards the DTLS message to the endpoint. In 100 this way, the DTLS association for the DTLS-SRTP procedures is 101 established between the endpoint and the key distributor, with the 102 media distributor simply forwarding packets between the two entities 103 and having no visibility into the confidential information exchanged. 105 Following the existing DTLS-SRTP procedures, the endpoint and key 106 distributor will arrive at a selected cipher and keying material, 107 which are used for HBH encryption and authentication by both the 108 endpoint and the media distributor. However, since the media 109 distributor would not have direct access to this information, the key 110 distributor explicitly shares the HBH key information with the media 111 distributor via the tunneling protocol defined in this document. 112 Additionally, the endpoint and key distributor will agree on a cipher 113 for E2E encryption and authentication. The key distributor will 114 transmit keying material to the endpoint for E2E operations, but will 115 not share that information with the media distributor. 117 By establishing this TLS tunnel between the media distributor and key 118 distributor and implementing the protocol defined in this document, 119 it is possible for the media distributor to facilitate the 120 establishment of a secure DTLS association between an endpoint and 121 the key distributor in order for the endpoint to receive E2E and HBH 122 keying material. At the same time, the key distributor can securely 123 provide the HBH keying material to the media distributor. 125 2. Conventions Used In This Document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Tunneling Concept 135 A TLS connection (tunnel) is established between the media 136 distributor and the key distributor. This tunnel is used to relay 137 DTLS messages between the endpoint and key distributor, as depicted 138 in Figure 1: 140 +-------------+ 141 | Key | 142 | Distributor | 143 +-------------+ 144 # ^ ^ # 145 # | | # <-- TLS Tunnel 146 # | | # 147 +----------+ +-------------+ +----------+ 148 | | DTLS | | DTLS | | 149 | Endpoint |<------------| Media |------------>| Endpoint | 150 | | to Key | Distributor | to Key | | 151 | | Distributor | | Distributor | | 152 +----------+ +-------------+ +----------+ 154 Figure 1: TLS Tunnel to Key Distributor 156 The three entities involved in this communication flow are the 157 endpoint, the media distributor, and the key distributor. The 158 behavior of each entity is described in Section 5. 160 The key distributor is a logical function that might might be co- 161 resident with a key management server operated by an enterprise, 162 reside in one of the endpoints participating in the conference, or 163 elsewhere that is trusted with E2E keying material. 165 4. Example Message Flows 167 This section provides an example message flow to help clarify the 168 procedures described later in this document. It is necessary that 169 the key distributor and media distributor establish a mutually 170 authenticated TLS connection for the purpose of sending tunneled 171 messages, though the complete TLS handshake for the tunnel is not 172 shown in Figure 2 since there is nothing new this document introduces 173 with regard to those procedures. 175 Once the tunnel is established, it is possible for the media 176 distributor to relay the DTLS messages between the endpoint and the 177 key distributor. Figure 2 shows a message flow wherein the endpoint 178 uses DTLS-SRTP to establish an association with the key distributor. 179 In the process, the media distributor shares its supported SRTP 180 protection profile information (see [RFC5764]) and the key 181 distributor shares HBH keying material and selected cipher with the 182 media distributor. 184 Endpoint media distributor key distributor 185 | | | 186 | |<=======================>| 187 | | TLS Connection Made | 188 | | | 189 | |========================>| 190 | | SupportedProfiles | 191 | | | 192 |------------------------>|========================>| 193 | DTLS handshake message | TunneledDtls | 194 | | | 195 | |<========================| 196 | | MediaKeys | 197 | | | 198 .... may be multiple handshake messages ... 199 | | | 200 |<------------------------|<========================| 201 | DTLS handshake message | TunneledDtls | 202 | | | 204 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 206 After the initial TLS connection has been established each of the 207 messages on the right-hand side of Figure 2 is a tunneling protocol 208 message as defined in Section 6. 210 SRTP protection profiles supported by the media distributor will be 211 sent in a "SupportedProfiles" message when the TLS tunnel is 212 initially established. The key distributor will use that information 213 to select a common profile supported by both the endpoint and the 214 media distributor to ensure that HBH operations can be successfully 215 performed. 217 As DTLS messages are received from the endpoint by the media 218 distributor, they are forwarded to the key distributor encapsulated 219 inside a "TunneledDtls" message. Likewise, as "TunneledDtls" 220 messages are received by the media distributor from the key 221 distributor, the encapsulated DTLS packet is forwarded to the 222 endpoint. 224 The key distributor will provide the SRTP [RFC3711] keying material 225 to the media distributor for HBH operations via the "MediaKeys" 226 message. The media distributor will extract this keying material 227 from the "MediaKeys" message when received and use it for HBH 228 encryption and authentication. 230 5. Tunneling Procedures 232 The following sub-sections explain in detail the expected behavior of 233 the endpoint, the media distributor, and the key distributor. 235 It is important to note that the tunneling protocol described in this 236 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 237 Rather, it is a protocol that transports DTLS messages generated by 238 an endpoint or key distributor as data inside of the TLS connection 239 established between the media distributor and key distributor. 241 5.1. Endpoint Procedures 243 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 244 in order to establish the cipher and keys used for encryption and 245 authentication, with the endpoint acting as the client and the key 246 distributor acting as the server. The endpoint does not need to be 247 aware of the fact that DTLS messages it transmits toward the media 248 distributor are being tunneled to the key distributor. 250 The endpoint MUST include a unique identifier in the "tls-id" SDP 251 [!@RFC4566] attribute sent by the endpoint in both offer and answer 252 [RFC3264] messages as per [RFC8842]. Further, the endpoint MUST 253 include this same unique identifier in the "external_session_id" 254 extension [RFC8844] in the "ClientHello" message when establishing a 255 DTLS association. 257 When receiving a "external_session_id" value from the key 258 distributor, the client MUST check to ensure that value matches the 259 "tls-id" value received in SDP. If the values do not match, the 260 endpoint MUST consider any received keying material to be invalid and 261 terminate the DTLS association. 263 5.2. Tunnel Establishment Procedures 265 Either the media distributor or key distributor initiates the 266 establishment of a TLS tunnel. Which entity acts as the TLS client 267 when establishing the tunnel and what event triggers the 268 establishment of the tunnel are outside the scope of this document. 269 Further, how the trust relationships are established between the key 270 distributor and media distributor are also outside the scope of this 271 document. 273 A tunnel MUST be a mutually authenticated TLS connection. 275 The media distributor or key distributor MUST establish a tunnel 276 prior to forwarding tunneled DTLS messages. Given the time-sensitive 277 nature of DTLS-SRTP procedures, a tunnel SHOULD be established prior 278 to the media distributor receiving a DTLS message from an endpoint. 280 A single tunnel MAY be used to relay DTLS messages between any number 281 of endpoints and the key distributor. 283 A media distributor MAY have more than one tunnel established between 284 itself and one or more key distributors. When multiple tunnels are 285 established, which tunnel or tunnels to use to send messages for a 286 given conference is outside the scope of this document. 288 5.3. Media Distributor Tunneling Procedures 290 The first message transmitted over the tunnel is the 291 "SupportedProfiles" (see Section 6). This message informs the key 292 distributor about which DTLS-SRTP profiles the media distributor 293 supports. This message MUST be sent each time a new tunnel 294 connection is established or, in the case of connection loss, when a 295 connection is re-established. The media distributor MUST support the 296 same list of protection profiles for the duration of any endpoint- 297 initiated DTLS association and tunnel connection. 299 The media distributor MUST assign a unique association identifier for 300 each endpoint-initiated DTLS association and include it in all 301 messages forwarded to the key distributor. The key distributor will 302 subsequently include this identifier in all messages it sends so that 303 the media distributor can map messages received via a tunnel and 304 forward those messages to the correct endpoint. The association 305 identifier MUST be randomly assigned UUID value as described 306 Section 4.4 of [RFC4122]. 308 When a DTLS message is received by the media distributor from an 309 endpoint, it forwards the UDP payload portion of that message to the 310 key distributor encapsulated in a "TuneledDtls" message. The media 311 distributor is not required to forward all messages received from an 312 endpoint for a given DTLS association through the same tunnel if more 313 than one tunnel has been established between it and a key 314 distributor. 316 When a "MediaKeys" message is received, the media distributor MUST 317 extract the cipher and keying material conveyed in order to 318 subsequently perform HBH encryption and authentication operations for 319 RTP and RTCP packets sent between it and an endpoint. Since the HBH 320 keying material will be different for each endpoint, the media 321 distributor uses the association identifier included by the key 322 distributor to ensure that the HBH keying material is used with the 323 correct endpoint. 325 The media distributor MUST forward all DTLS messages received from 326 either the endpoint or the key distributor (via the "TunneledDtls" 327 message) to ensure proper communication between those two entities. 329 When the media distributor detects an endpoint has disconnected or 330 when it receives conference control messages indicating the endpoint 331 is to be disconnected, the media distributors MUST send an 332 "EndpointDisconnect" message with the association identifier assigned 333 to the endpoint to the key distributor. The media distributor SHOULD 334 take a loss of all RTP and RTCP packets as an indicator that the 335 endpoint has disconnected. The particulars of how RTP and RTCP are 336 to be used to detect an endpoint disconnect, such as timeout period, 337 is not specified. The media distributor MAY use additional 338 indicators to determine when an endpoint has disconnected. 340 5.4. Key Distributor Tunneling Procedures 342 Each TLS tunnel established between the media distributor and the key 343 distributor MUST be mutually authenticated. 345 When the media distributor relays a DTLS message from an endpoint, 346 the media distributor will include an association identifier that is 347 unique per endpoint-originated DTLS association. The association 348 identifier remains constant for the life of the DTLS association. 349 The key distributor identifies each distinct endpoint-originated DTLS 350 association by the association identifier. 352 When processing an incoming endpoint association, the key distributor 353 MUST extract the "external_session_id" value transmitted in the 354 "ClientHello" message and match that against "tls-id" value the 355 endpoint transmitted via SDP. If the values in SDP and the 356 "ClientHello" do not match, the DTLS association MUST be rejected. 358 The process through which the "tls-id" in SDP is conveyed to the key 359 distributor is outside the scope of this document. 361 The key distributor MUST match the certificate fingerprint and 362 "external_session_id" received from endpoint's "ClientHello" message 363 with the values received from the SDP transmitted by the endpoint. 364 It is through this process that the key distributor can be sure to 365 deliver the correct conference key to the endpoint. 367 When sending the "ServerHello" message, the key distributor MUST 368 insert its own unique identifier in the "external_session_id" 369 extension. This value MUST also be conveyed back to the client via 370 SDP as a "tls-id" attribute. 372 The key distributor MUST encapsulate any DTLS message it sends to an 373 endpoint inside a "TunneledDtls" message (see Section 6). The key 374 distributor is not required to transmit all messages a given DTLS 375 association through the same tunnel if more than one tunnel has been 376 established between it and a media distributor. 378 The key distributor MUST use the same association identifier in 379 messages sent to an endpoint as was received in messages from that 380 endpoint. This ensures the media distributor can forward the 381 messages to the correct endpoint. 383 The key distributor extracts tunneled DTLS messages from an endpoint 384 and acts on those messages as if that endpoint had established the 385 DTLS association directly with the key distributor. The key 386 distributor is acting as the DTLS server and the endpoint is acting 387 as the DTLS client. The handling of the messages and certificates is 388 exactly the same as normal DTLS-SRTP procedures between endpoints. 390 The key distributor MUST send a "MediaKeys" message to the media 391 distributor as soon as the HBH encryption key is computed and before 392 it sends a DTLS "Finished" message to the endpoint. The "MediaKeys" 393 message includes the selected cipher (i.e. protection profile), MKI 394 [RFC3711] value (if any), SRTP master keys, and SRTP master salt 395 values. The key distributor MUST use the same association identifier 396 in the "MediaKeys" message as is used in the "TunneledDtls" messages 397 for the given endpoint. 399 The key distributor uses the certificate fingerprint of the endpoint 400 along with the unique identifier received in the 401 "external_session_id" extension to determine which conference a given 402 DTLS association is associated. 404 The key distributor MUST select a cipher that is supported by both 405 the endpoint and the media distributor to ensure proper HBH 406 operations. 408 When the DTLS association between the endpoint and the key 409 distributor is terminated, regardless of which entity initiated the 410 termination, the key distributor MUST send an "EndpointDisconnect" 411 message with the association identifier assigned to the endpoint to 412 the media distributor. 414 5.5. Versioning Considerations 416 All messages for an established tunnel MUST utilize the same version 417 value. 419 Since the media distributor sends the first message over the tunnel, 420 it effectively establishes the version of the protocol to be used. 421 If that version is not supported by the key distributor, it MUST 422 discard the message, transmit an "UnsupportedVersion" message, and 423 close the TLS connection. 425 The media distributor MUST take note of the version received in an 426 "UnsupportedVersion" message and use that version when attempting to 427 re-establish a failed tunnel connection. Note that it is not 428 necessary for the media distributor to understand the newer version 429 of the protocol to understand that the first message received is 430 "UnsupportedVersion". The media distributor can determine from the 431 first two octets received what the version number is and that the 432 message is "UnsupportedVersion". The rest of the data received, if 433 any, would be discarded and the connection closed (if not already 434 closed). 436 6. Tunneling Protocol 438 Tunneled messages are transported via the TLS tunnel as application 439 data between the media distributor and the key distributor. Tunnel 440 messages are specified using the format described in [RFC5246] 441 section 4. As in [RFC5246], all values are stored in network byte 442 (big endian) order; the uint32 represented by the hex bytes 01 02 03 443 04 is equivalent to the decimal value 16909060. 445 The protocol defines several different messages, each of which 446 containing the the following information: 448 * Protocol version 450 * Message type identifier 452 * The message body 454 Each of these messages is a "TunnelMessage" in the syntax, with a 455 message type indicating the actual content of the message body. 457 6.1. Tunnel Message Format 459 The syntax of the protocol is defined below. "TunnelMessage" defines 460 the structure of all messages sent via the tunnel protocol. That 461 structure includes a field called "msg_type" that identifies the 462 specific type of message contained within "TunnelMessage". 464 enum { 465 supported_profiles(1), 466 unsupported_version(2), 467 media_keys(3), 468 tunneled_dtls(4), 469 endpoint_disconnect(5), 470 (255) 471 } MsgType; 473 opaque uuid[16]; 475 struct { 476 MsgType msg_type; 477 uint16 length; 478 select (MsgType) { 479 case supported_profiles: SupportedProfiles; 480 case unsupported_version: UnsupportedVersion; 481 case media_keys: MediaKeys; 482 case tunneled_dtls: TunneledDtls; 483 case endpoint_disconnect: EndpointDisconnect; 484 } body; 485 } TunnelMessage; 487 The elements of "TunnelMessage" include: 489 * msg_type: the type of message contained within the structure 490 "body". 492 * length: the length in octets of the following "body" of the 493 message. 495 The "SupportedProfiles" message is defined as: 497 uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ 499 struct { 500 uint8 version; 501 SRTPProtectionProfile protection_profiles<0..2^16-1>; 502 } SupportedProfiles; 504 This message contains this single element: 506 * version: indicates the version of this protocol (0x00). 508 * protection_profiles: The list of two-octet SRTP protection profile 509 values as per [RFC5764] supported by the media distributor. 511 The "UnsupportedVersion" message is defined as follows: 513 struct { 514 uint8 highest_version; 515 } UnsupportedVersion; 517 The elements of "UnsupportedVersion" include: 519 * highest_version: indicates the highest supported protocol version. 521 The "MediaKeys" message is defined as: 523 struct { 524 uuid association_id; 525 SRTPProtectionProfile protection_profile; 526 opaque mki<0..255>; 527 opaque client_write_SRTP_master_key<1..255>; 528 opaque server_write_SRTP_master_key<1..255>; 529 opaque client_write_SRTP_master_salt<1..255>; 530 opaque server_write_SRTP_master_salt<1..255>; 531 } MediaKeys; 533 The fields are described as follows: 535 * association_id: A value that identifies a distinct DTLS 536 association between an endpoint and the key distributor. 538 * protection_profiles: The value of the two-octet SRTP protection 539 profile value as per [RFC5764] used for this DTLS association. 541 * mki: Master key identifier [RFC3711]. A zero-length field 542 indicates that no MKI value is present. 544 * client_write_SRTP_master_key: The value of the SRTP master key 545 used by the client (endpoint). 547 * server_write_SRTP_master_key: The value of the SRTP master key 548 used by the server (media distributor). 550 * client_write_SRTP_master_salt: The value of the SRTP master salt 551 used by the client (endpoint). 553 * server_write_SRTP_master_salt: The value of the SRTP master salt 554 used by the server (media distributor). 556 The "TunneledDtls" message is defined as: 558 struct { 559 uuid association_id; 560 opaque dtls_message<0..2^16-1>; 561 } TunneledDtls; 563 The fields are described as follows: 565 * association_id: An value that identifies a distinct DTLS 566 association between an endpoint and the key distributor. 568 * dtls_message: the content of the DTLS message received by the 569 endpoint or to be sent to the endpoint. 571 The "EndpointDisconect" message is defined as: 573 struct { 574 uuid association_id; 575 } EndpointDisconnect; 577 The fields are described as follows: 579 * association_id: An value that identifies a distinct DTLS 580 association between an endpoint and the key distributor. 582 7. Example Binary Encoding 584 The "TunnelMessage" is encoded in binary following the procedures 585 specified in [RFC5246]. This section provides an example of what the 586 bits on the wire would look like for the "SupportedProfiles" message 587 that advertises support for both 588 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 589 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [RFC8723]. 591 TunnelMessage: 592 message_type: 0x01 593 length: 0x0007 594 SupportedProfiles: 595 version: 0x00 596 protection_profiles: 0x0004 (length) 597 0x0009000A (value) 599 Thus, the encoding on the wire presented here in network bytes order 600 would be this stream of octets: 602 0x0100070000040009000A 604 8. IANA Considerations 606 This document establishes a new registry to contain message type 607 values used in the DTLS Tunnel protocol. These data type values are 608 a single octet in length. This document defines the values shown in 609 Table 1 below, leaving the balance of possible values reserved for 610 future specifications: 612 +=========+====================================+ 613 | MsgType | Description | 614 +=========+====================================+ 615 | 0x01 | Supported SRTP Protection Profiles | 616 +---------+------------------------------------+ 617 | 0x02 | Unsupported Version | 618 +---------+------------------------------------+ 619 | 0x03 | Media Keys | 620 +---------+------------------------------------+ 621 | 0x04 | Tunneled DTLS | 622 +---------+------------------------------------+ 623 | 0x05 | Endpoint Disconnect | 624 +---------+------------------------------------+ 626 Table 1: Data Type Values for the DTLS 627 Tunnel Protocol 629 The value 0x00 and all values in the range 0x06 to 0xFF are reserved. 631 The name for this registry is "Datagram Transport Layer Security 632 (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing". 634 The procedures for updating this table are those defined as "IETF 635 Review" in section 4.8 if [!@RFC8126]. 637 9. Security Considerations 639 The encapsulated data is protected by the TLS connection from the 640 endpoint to key distributor, and the media distributor is merely an 641 on path entity. The media distributor does not have access to the 642 end-to-end keying material This does not introduce any additional 643 security concerns beyond a normal DTLS-SRTP association. 645 The HBH keying material is protected by the mutual authenticated TLS 646 connection between the media distributor and key distributor. The 647 key distributor MUST ensure that it only forms associations with 648 authorized media distributors or it could hand HBH keying material to 649 untrusted parties. 651 The supported profiles information sent from the media distributor to 652 the key distributor is not particularly sensitive as it only provides 653 the cryptographic algorithms supported by the media distributor. 654 Further, it is still protected by the TLS connection between the 655 media distributor and the key distributor. 657 10. Acknowledgments 659 The author would like to thank David Benham and Cullen Jennings for 660 reviewing this document and providing constructive comments. 662 11. Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, 666 DOI 10.17487/RFC2119, March 1997, 667 . 669 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 670 with Session Description Protocol (SDP)", RFC 3264, 671 DOI 10.17487/RFC3264, June 2002, 672 . 674 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 675 Jacobson, "RTP: A Transport Protocol for Real-Time 676 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 677 July 2003, . 679 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 680 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 681 RFC 3711, DOI 10.17487/RFC3711, March 2004, 682 . 684 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 685 Unique IDentifier (UUID) URN Namespace", RFC 4122, 686 DOI 10.17487/RFC4122, July 2005, 687 . 689 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 690 (TLS) Protocol Version 1.2", RFC 5246, 691 DOI 10.17487/RFC5246, August 2008, 692 . 694 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 695 Security (DTLS) Extension to Establish Keys for the Secure 696 Real-time Transport Protocol (SRTP)", RFC 5764, 697 DOI 10.17487/RFC5764, May 2010, 698 . 700 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 701 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 702 January 2012, . 704 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 705 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 706 May 2017, . 708 [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol 709 (SDP) Offer/Answer Considerations for Datagram Transport 710 Layer Security (DTLS) and Transport Layer Security (TLS)", 711 RFC 8842, DOI 10.17487/RFC8842, January 2021, 712 . 714 [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on 715 Uses of TLS with the Session Description Protocol (SDP)", 716 RFC 8844, DOI 10.17487/RFC8844, January 2021, 717 . 719 [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution 720 Framework for Private Media in Privacy-Enhanced RTP 721 Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, 722 January 2021, . 724 12. Informative References 726 [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, 727 "Double Encryption Procedures for the Secure Real-Time 728 Transport Protocol (SRTP)", RFC 8723, 729 DOI 10.17487/RFC8723, April 2020, 730 . 732 Authors' Addresses 734 Paul E. Jones 735 Cisco Systems, Inc. 736 7025 Kit Creek Rd. 737 Research Triangle Park, North Carolina 27709 738 United States of America 740 Phone: +1 919 476 2048 741 Email: paulej@packetizer.com 743 Paul M. Ellenbogen 744 Princeton University 746 Phone: +1 206 851 2069 747 Email: pe5@cs.princeton.edu 749 Nils H. Ohlmeier 750 Mozilla 752 Phone: +1 408 659 6457 753 Email: nils@ohlmeier.org