idnits 2.17.1 draft-ietf-perc-dtls-tunnel-09.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 (13 June 2021) is 1019 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 478 -- Looks like a reference, but probably isn't: '2' on line 507 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 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: 15 December 2021 Princeton University 6 N. Ohlmeier 7 8x8, Inc. 8 13 June 2021 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-ietf-perc-dtls-tunnel-09 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 15 December 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 . . . . . . . . . . . . . . . . . . . . . . 4 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. TunnelMessage Structure . . . . . . . . . . . . . . . . . 10 69 6.2. SupportedProfiles Message . . . . . . . . . . . . . . . . 11 70 6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12 71 6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12 72 6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13 73 6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13 74 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 79 12. Informative References . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is 85 to ensure that endpoints in a multimedia conference have access to 86 the end-to-end (E2E) and hop-by-hop (HBH) keying material used to 87 encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] 88 packets, while the Media Distributor has access only to the HBH 89 keying material for encryption and authentication. 91 This specification defines a tunneling protocol that enables the 92 Media Distributor to tunnel DTLS [RFC6347] messages between an 93 endpoint and the Key Distributor, thus allowing an endpoint to use 94 DTLS-SRTP [RFC5764] for establishing encryption and authentication 95 keys with the Key Distributor. 97 The tunnel established between the Media Distributor and Key 98 Distributor is a TLS [RFC5246] connection that is established before 99 any messages are forwarded by the Media Distributor on behalf of the 100 endpoint. DTLS packets received from the endpoint are encapsulated 101 by the Media Distributor inside this tunnel as data to be sent to the 102 Key Distributor. Likewise, when the Media Distributor receives data 103 from the Key Distributor over the tunnel, it extracts the DTLS 104 message inside and forwards the DTLS message to the endpoint. In 105 this way, the DTLS association for the DTLS-SRTP procedures is 106 established between the endpoint and the Key Distributor, with the 107 Media Distributor simply forwarding packets between the two entities 108 and having no visibility into the confidential information exchanged. 110 Following the existing DTLS-SRTP procedures, the endpoint and Key 111 Distributor will arrive at a selected cipher and keying material, 112 which are used for HBH encryption and authentication by both the 113 endpoint and the Media Distributor. However, since the Media 114 Distributor would not have direct access to this information, the Key 115 Distributor explicitly shares the HBH key information with the Media 116 Distributor via the tunneling protocol defined in this document. 117 Additionally, the endpoint and Key Distributor will agree on a cipher 118 for E2E encryption and authentication. The Key Distributor will 119 transmit keying material to the endpoint for E2E operations, but will 120 not share that information with the Media Distributor. 122 By establishing this TLS tunnel between the Media Distributor and Key 123 Distributor and implementing the protocol defined in this document, 124 it is possible for the Media Distributor to facilitate the 125 establishment of a secure DTLS association between an endpoint and 126 the Key Distributor in order for the endpoint to receive E2E and HBH 127 keying material. At the same time, the Key Distributor can securely 128 provide the HBH keying material to the Media Distributor. 130 2. Conventions Used In This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 This document uses the terms "endpoint", "Media Distributor", and 139 "Key Distributor" defined in [RFC8871]. 141 3. Tunneling Concept 143 A TLS connection (tunnel) is established between the Media 144 Distributor and the Key Distributor. This tunnel is used to relay 145 DTLS messages between the endpoint and Key Distributor, as depicted 146 in Figure 1: 148 +-------------+ 149 | Key | 150 | Distributor | 151 +-------------+ 152 # ^ ^ # 153 # | | # <-- TLS Tunnel 154 # | | # 155 +----------+ +-------------+ +----------+ 156 | | DTLS | | DTLS | | 157 | Endpoint |<------------| Media |------------>| Endpoint | 158 | | to Key | Distributor | to Key | | 159 | | Distributor | | Distributor | | 160 +----------+ +-------------+ +----------+ 162 Figure 1: TLS Tunnel to Key Distributor 164 The three entities involved in this communication flow are the 165 endpoint, the Media Distributor, and the Key Distributor. The 166 behavior of each entity is described in Section 5. 168 The Key Distributor is a logical function that might be co-resident 169 with a key management server operated by an enterprise, reside in one 170 of the endpoints participating in the conference, or elsewhere that 171 is trusted with E2E keying material. 173 4. Example Message Flows 175 This section provides an example message flow to help clarify the 176 procedures described later in this document. It is necessary that 177 the Key Distributor and Media Distributor establish a mutually 178 authenticated TLS connection for the purpose of sending tunneled 179 messages, though the complete TLS handshake for the tunnel is not 180 shown in Figure 2 since there is nothing new this document introduces 181 with regard to those procedures. 183 Once the tunnel is established, it is possible for the Media 184 Distributor to relay the DTLS messages between the endpoint and the 185 Key Distributor. Figure 2 shows a message flow wherein the endpoint 186 uses DTLS-SRTP to establish an association with the Key Distributor. 187 In the process, the Media Distributor shares its supported SRTP 188 protection profile information (see [RFC5764]) and the Key 189 Distributor shares HBH keying material and selected cipher with the 190 Media Distributor. 192 Endpoint Media Distributor Key Distributor 193 | | | 194 | |<=======================>| 195 | | TLS Connection Made | 196 | | | 197 | |========================>| 198 | | SupportedProfiles | 199 | | | 200 |------------------------>|========================>| 201 | DTLS handshake message | TunneledDtls | 202 | | | 203 | |<========================| 204 | | MediaKeys | 205 | | | 206 .... may be multiple handshake messages ... 207 | | | 208 |<------------------------|<========================| 209 | DTLS handshake message | TunneledDtls | 210 | | | 212 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 214 After the initial TLS connection has been established each of the 215 messages on the right-hand side of Figure 2 is a tunneling protocol 216 message as defined in Section 6. 218 SRTP protection profiles supported by the Media Distributor will be 219 sent in a "SupportedProfiles" message when the TLS tunnel is 220 initially established. The Key Distributor will use that information 221 to select a common profile supported by both the endpoint and the 222 Media Distributor to ensure that HBH operations can be successfully 223 performed. 225 As DTLS messages are received from the endpoint by the Media 226 Distributor, they are forwarded to the Key Distributor encapsulated 227 inside a "TunneledDtls" message. Likewise, as "TunneledDtls" 228 messages are received by the Media Distributor from the Mey 229 Distributor, the encapsulated DTLS packet is forwarded to the 230 endpoint. 232 The Key Distributor will provide the SRTP [RFC3711] keying material 233 to the Media Distributor for HBH operations via the "MediaKeys" 234 message. The Media Distributor will extract this keying material 235 from the "MediaKeys" message when received and use it for HBH 236 encryption and authentication. 238 5. Tunneling Procedures 240 The following sub-sections explain in detail the expected behavior of 241 the endpoint, the Media Distributor, and the Key Distributor. 243 It is important to note that the tunneling protocol described in this 244 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 245 Rather, it is a protocol that transports DTLS messages generated by 246 an endpoint or Key Distributor as data inside of the TLS connection 247 established between the Media Distributor and Key Distributor. 249 5.1. Endpoint Procedures 251 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 252 in order to establish the cipher and keys used for encryption and 253 authentication, with the endpoint acting as the client and the Key 254 Distributor acting as the server. The endpoint does not need to be 255 aware of the fact that DTLS messages it transmits toward the Media 256 Distributor are being tunneled to the Key Distributor. 258 The endpoint MUST include a unique identifier in the "tls-id" SDP 259 [RFC4566] attribute sent by the endpoint in both offer and answer 260 [RFC3264] messages as per [RFC8842]. Further, the endpoint MUST 261 include this same unique identifier in the "external_session_id" 262 extension [RFC8844] in the "ClientHello" message when establishing a 263 DTLS association. 265 When receiving a "external_session_id" value from the Key 266 Distributor, the client MUST check to ensure that value matches the 267 "tls-id" value received in SDP. If the values do not match, the 268 endpoint MUST consider any received keying material to be invalid and 269 terminate the DTLS association. 271 5.2. Tunnel Establishment Procedures 273 Either the Media Distributor or Key Distributor initiates the 274 establishment of a TLS tunnel. Which entity acts as the TLS client 275 when establishing the tunnel and what event triggers the 276 establishment of the tunnel are outside the scope of this document. 277 Further, how the trust relationships are established between the Key 278 Distributor and Media Distributor are also outside the scope of this 279 document. 281 A tunnel MUST be a mutually authenticated TLS connection. 283 The Media Distributor or Key Distributor MUST establish a tunnel 284 prior to forwarding tunneled DTLS messages. Given the time-sensitive 285 nature of DTLS-SRTP procedures, a tunnel SHOULD be established prior 286 to the Media Distributor receiving a DTLS message from an endpoint. 288 A single tunnel MAY be used to relay DTLS messages between any number 289 of endpoints and the Key Distributor. 291 A Media Distributor MAY have more than one tunnel established between 292 itself and one or more Key Distributors. When multiple tunnels are 293 established, which tunnel or tunnels to use to send messages for a 294 given conference is outside the scope of this document. 296 5.3. Media Distributor Tunneling Procedures 298 The first message transmitted over the tunnel is the 299 "SupportedProfiles" (see Section 6). This message informs the Key 300 Distributor about which DTLS-SRTP profiles the Media Distributor 301 supports. This message MUST be sent each time a new tunnel 302 connection is established or, in the case of connection loss, when a 303 connection is re-established. The Media Distributor MUST support the 304 same list of protection profiles for the duration of any endpoint- 305 initiated DTLS association and tunnel connection. 307 The Media Distributor MUST assign a unique association identifier for 308 each endpoint-initiated DTLS association and include it in all 309 messages forwarded to the Key Distributor. The Key Distributor will 310 subsequently include this identifier in all messages it sends so that 311 the Media Distributor can map messages received via a tunnel and 312 forward those messages to the correct endpoint. The association 313 identifier MUST be randomly assigned UUID value as described 314 Section 4.4 of [RFC4122]. 316 When a DTLS message is received by the Media Distributor from an 317 endpoint, it forwards the UDP payload portion of that message to the 318 Key Distributor encapsulated in a "TuneledDtls" message. The Media 319 Distributor is not required to forward all messages received from an 320 endpoint for a given DTLS association through the same tunnel if more 321 than one tunnel has been established between it and a Key 322 Distributor. 324 When a "MediaKeys" message is received, the Media Distributor MUST 325 extract the cipher and keying material conveyed in order to 326 subsequently perform HBH encryption and authentication operations for 327 RTP and RTCP packets sent between it and an endpoint. Since the HBH 328 keying material will be different for each endpoint, the Media 329 Distributor uses the association identifier included by the Key 330 Distributor to ensure that the HBH keying material is used with the 331 correct endpoint. 333 The Media Distributor MUST forward all DTLS messages received from 334 either the endpoint or the Key Distributor (via the "TunneledDtls" 335 message) to ensure proper communication between those two entities. 337 When the Media Distributor detects an endpoint has disconnected or 338 when it receives conference control messages indicating the endpoint 339 is to be disconnected, the Media Distributors MUST send an 340 "EndpointDisconnect" message with the association identifier assigned 341 to the endpoint to the Key Distributor. The Media Distributor SHOULD 342 take a loss of all RTP and RTCP packets as an indicator that the 343 endpoint has disconnected. The particulars of how RTP and RTCP are 344 to be used to detect an endpoint disconnect, such as timeout period, 345 is not specified. The Media Distributor MAY use additional 346 indicators to determine when an endpoint has disconnected. 348 5.4. Key Distributor Tunneling Procedures 350 Each TLS tunnel established between the Media Distributor and the Key 351 Distributor MUST be mutually authenticated. 353 When the Media Distributor relays a DTLS message from an endpoint, 354 the Media Distributor will include an association identifier that is 355 unique per endpoint-originated DTLS association. The association 356 identifier remains constant for the life of the DTLS association. 357 The Key Distributor identifies each distinct endpoint-originated DTLS 358 association by the association identifier. 360 When processing an incoming endpoint association, the Key Distributor 361 MUST extract the "external_session_id" value transmitted in the 362 "ClientHello" message and match that against "tls-id" value the 363 endpoint transmitted via SDP. If the values in SDP and the 364 "ClientHello" do not match, the DTLS association MUST be rejected. 366 The process through which the "tls-id" in SDP is conveyed to the Key 367 Distributor is outside the scope of this document. 369 The Key Distributor MUST match the certificate fingerprint and 370 "external_session_id" received from endpoint's "ClientHello" message 371 with the values received from the SDP transmitted by the endpoint. 372 It is through this process that the Key Distributor can be sure to 373 deliver the correct conference key to the endpoint. 375 When sending the "ServerHello" message, the Key Distributor MUST 376 insert its own unique identifier in the "external_session_id" 377 extension. This value MUST also be conveyed back to the client via 378 SDP as a "tls-id" attribute. 380 The Key Distributor MUST encapsulate any DTLS message it sends to an 381 endpoint inside a "TunneledDtls" message (see Section 6). The Key 382 Distributor is not required to transmit all messages a given DTLS 383 association through the same tunnel if more than one tunnel has been 384 established between it and a Media Distributor. 386 The Key Distributor MUST use the same association identifier in 387 messages sent to an endpoint as was received in messages from that 388 endpoint. This ensures the Media Distributor can forward the 389 messages to the correct endpoint. 391 The Key Distributor extracts tunneled DTLS messages from an endpoint 392 and acts on those messages as if that endpoint had established the 393 DTLS association directly with the Key Distributor. The Key 394 Distributor is acting as the DTLS server and the endpoint is acting 395 as the DTLS client. The handling of the messages and certificates is 396 exactly the same as normal DTLS-SRTP procedures between endpoints. 398 The Key Distributor MUST send a "MediaKeys" message to the Media 399 Distributor as soon as the HBH encryption key is computed and before 400 it sends a DTLS "Finished" message to the endpoint. The "MediaKeys" 401 message includes the selected cipher (i.e. protection profile), MKI 402 [RFC3711] value (if any), SRTP master keys, and SRTP master salt 403 values. The Key Distributor MUST use the same association identifier 404 in the "MediaKeys" message as is used in the "TunneledDtls" messages 405 for the given endpoint. 407 The Key Distributor uses the certificate fingerprint of the endpoint 408 along with the unique identifier received in the 409 "external_session_id" extension to determine which conference a given 410 DTLS association is associated. 412 The Key Distributor MUST select a cipher that is supported by both 413 the endpoint and the Media Distributor to ensure proper HBH 414 operations. 416 When the DTLS association between the endpoint and the Key 417 Distributor is terminated, regardless of which entity initiated the 418 termination, the Key Distributor MUST send an "EndpointDisconnect" 419 message with the association identifier assigned to the endpoint to 420 the Media Distributor. 422 5.5. Versioning Considerations 424 Since the Media Distributor sends the first message over the tunnel, 425 it effectively establishes the version of the protocol to be used. 426 If that version is not supported by the Key Distributor, the Key 427 Distributor MUST transmit an "UnsupportedVersion" message containing 428 the highest version number supported, and close the TLS connection. 430 The Media Distributor MUST take note of the version received in an 431 "UnsupportedVersion" message and use that version when attempting to 432 re-establish a failed tunnel connection. Note that it is not 433 necessary for the Media Distributor to understand the newer version 434 of the protocol to understand that the first message received is 435 "UnsupportedVersion". The Media Distributor can determine from the 436 first two octets received what the version number is and that the 437 message is "UnsupportedVersion". The rest of the data received, if 438 any, would be discarded and the connection closed (if not already 439 closed). 441 6. Tunneling Protocol 443 Tunneled messages are transported via the TLS tunnel as application 444 data between the Media Distributor and the Key Distributor. Tunnel 445 messages are specified using the format described in [RFC5246] 446 section 4. As in [RFC5246], all values are stored in network byte 447 (big endian) order; the uint32 represented by the hex bytes 01 02 03 448 04 is equivalent to the decimal value 16909060. 450 This protocol defines several different messages, each of which 451 contains the following information: 453 * Message type identifier 455 * Message body length 457 * The message body 459 Each of the tunnel messages is a "TunnelMessage" structure with the 460 message type indicating the actual content of the message body. 462 6.1. TunnelMessage Structure 464 The "TunnelMessage" defines the structure of all messages sent via 465 the tunnel protocol. That structure includes a field called 466 "msg_type" that identifies the specific type of message contained 467 within "TunnelMessage". 469 enum { 470 supported_profiles(1), 471 unsupported_version(2), 472 media_keys(3), 473 tunneled_dtls(4), 474 endpoint_disconnect(5), 475 (255) 476 } MsgType; 478 opaque uuid[16]; 480 struct { 481 MsgType msg_type; 482 uint16 length; 483 select (MsgType) { 484 case supported_profiles: SupportedProfiles; 485 case unsupported_version: UnsupportedVersion; 486 case media_keys: MediaKeys; 487 case tunneled_dtls: TunneledDtls; 488 case endpoint_disconnect: EndpointDisconnect; 489 } body; 490 } TunnelMessage; 492 The elements of "TunnelMessage" include: 494 * "msg_type": the type of message contained within the structure 495 "body". 497 * "length": the length in octets of the following "body" of the 498 message. 500 * "body": the actual message being conveyed within this 501 "TunnelMessage" structure. 503 6.2. SupportedProfiles Message 505 The "SupportedProfiles" message is defined as: 507 uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ 509 struct { 510 uint8 version; 511 SRTPProtectionProfile protection_profiles<0..2^16-1>; 512 } SupportedProfiles; 514 This message contains this single element: 516 * "version": indicates the version of the protocol to use (0x00). 518 * "protection_profiles": The list of two-octet SRTP protection 519 profile values as per [RFC5764] supported by the Media 520 Distributor. 522 6.3. UnsupportedVersion Message 524 The "UnsupportedVersion" message is defined as follows: 526 struct { 527 uint8 highest_version; 528 } UnsupportedVersion; 530 The elements of "UnsupportedVersion" include: 532 * "highest_version": indicates the highest version of the protocol 533 supported by the Key Distributor. 535 6.4. MediaKeys Message 537 The "MediaKeys" message is defined as: 539 struct { 540 uuid association_id; 541 SRTPProtectionProfile protection_profile; 542 opaque mki<0..255>; 543 opaque client_write_SRTP_master_key<1..255>; 544 opaque server_write_SRTP_master_key<1..255>; 545 opaque client_write_SRTP_master_salt<1..255>; 546 opaque server_write_SRTP_master_salt<1..255>; 547 } MediaKeys; 549 The fields are described as follows: 551 * "association_id": A value that identifies a distinct DTLS 552 association between an endpoint and the Key Distributor. 554 * "protection_profiles": The value of the two-octet SRTP protection 555 profile value as per [RFC5764] used for this DTLS association. 557 * "mki": Master key identifier [RFC3711]. A zero-length field 558 indicates that no MKI value is present. 560 * "client_write_SRTP_master_key": The value of the SRTP master key 561 used by the client (endpoint). 563 * "server_write_SRTP_master_key": The value of the SRTP master key 564 used by the server (Media Distributor). 566 * "client_write_SRTP_master_salt": The value of the SRTP master salt 567 used by the client (endpoint). 569 * "server_write_SRTP_master_salt": The value of the SRTP master salt 570 used by the server (Media Distributor). 572 6.5. TunneledDtls Message 574 The "TunneledDtls" message is defined as: 576 struct { 577 uuid association_id; 578 opaque dtls_message<0..2^16-1>; 579 } TunneledDtls; 581 The fields are described as follows: 583 * "association_id": A value that identifies a distinct DTLS 584 association between an endpoint and the Key Distributor. 586 * "dtls_message": the content of the DTLS message received by the 587 endpoint or to be sent to the endpoint. 589 6.6. EndpointDisconnect Message 591 The "EndpointDisconnect" message is defined as: 593 struct { 594 uuid association_id; 595 } EndpointDisconnect; 597 The fields are described as follows: 599 * "association_id": An value that identifies a distinct DTLS 600 association between an endpoint and the Key Distributor. 602 7. Example Binary Encoding 604 The "TunnelMessage" is encoded in binary following the procedures 605 specified in [RFC5246]. This section provides an example of what the 606 bits on the wire would look like for the "SupportedProfiles" message 607 that advertises support for both 608 "DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and 609 "DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723]. 611 TunnelMessage: 612 message_type: 0x01 613 length: 0x0007 614 SupportedProfiles: 615 version: 0x00 616 protection_profiles: 0x0004 (length) 617 0x0009000A (value) 619 Thus, the encoding on the wire presented here in network bytes order 620 would be this stream of octets: 622 0x0100070000040009000A 624 8. IANA Considerations 626 This document establishes a new registry to contain message type 627 values used in the DTLS Tunnel protocol. These message type values 628 are a single octet in length. This document defines the values shown 629 in Table 1 below, leaving the balance of possible values reserved for 630 future specifications: 632 +=========+====================================+ 633 | MsgType | Description | 634 +=========+====================================+ 635 | 0x01 | Supported SRTP Protection Profiles | 636 +---------+------------------------------------+ 637 | 0x02 | Unsupported Version | 638 +---------+------------------------------------+ 639 | 0x03 | Media Keys | 640 +---------+------------------------------------+ 641 | 0x04 | Tunneled DTLS | 642 +---------+------------------------------------+ 643 | 0x05 | Endpoint Disconnect | 644 +---------+------------------------------------+ 646 Table 1: Message Type Values for the DTLS 647 Tunnel Protocol 649 The value 0x00 is reserved and all values in the range 0x06 to 0xFF 650 are available for allocation. The procedures for updating this table 651 are those defined as "IETF Review" in section 4.8 of [RFC8126]. 653 The name for this registry is "Datagram Transport Layer Security 654 (DTLS) Tunnel Protocol Message Types for Privacy Enhanced 655 Conferencing". 657 9. Security Considerations 659 Since the procedures in this document relies on TLS [RFC5246] for 660 transport security, the security considerations for TLS should be 661 reviewed when implementing the protocol defined in this document. 663 While the tunneling protocol defined in this document does not use 664 DTLS-SRTP [[RFC5764] directly, it does convey and negotiate some of 665 the same information (e.g., protection profile data). As such, a 666 review of the security considerations found in that document may be 667 useful. 669 This document describes a means of securely exchanging keying 670 material and cryptographic transforms for both E2E and HBH encryption 671 and authentication of media between an endpoint and a Key Distributor 672 via a Media Distributor. Additionally, the procedures result in 673 delivering HBH information to the intermediary Media Distributor. 674 The Key Distributor and endpoint are the only two entities with 675 access to both the E2E and HBH keys, while the Media Distributor has 676 access to only HBH information. Section 8.2 of [RFC8871] enumerates 677 various attacks against which one must guard when implementing a 678 Media Distributor and are important to note. 680 A requirement in this document is that a TLS connection between the 681 Media Distributor and the Key Distributor be mutually authenticated. 682 The reason for this requirement is to ensure that only an authorized 683 Media Distributor receives the HBH keying material. If an 684 unauthorized Media Distributor gains access to the HBH keying 685 material, it can easily cause service degradation or denial by 686 transmitting HBH-valid packets that ultimately fail E2E 687 authentication or replay protection checks (see Section 3.3.2 of 688 [RFC3711]). Even if service does not appear degraded in any way, 689 transmitting and processing bogus packets are a waste of both 690 computational and network resources. 692 While E2E keying material passes through the Media Distributor via 693 the protocol defined in this document, the Media Distributor has no 694 means of gaining access to that information and therefore cannot 695 affect the E2E media processing function in the endpoint except to 696 present it with invalid or replayed data. That said, any entity 697 along the path that interferes with the DTLS exchange between the 698 endpoint and the Key Distributor, including a malicious Media 699 Distributor that is not properly authorized, could prevent an 700 endpoint from properly communicating with the Key Distributor and, 701 therefore, prevent successful conference participation. 703 10. Acknowledgments 705 The author would like to thank David Benham and Cullen Jennings for 706 reviewing this document and providing constructive comments. 708 11. Normative References 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, 712 DOI 10.17487/RFC2119, March 1997, 713 . 715 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 716 with Session Description Protocol (SDP)", RFC 3264, 717 DOI 10.17487/RFC3264, June 2002, 718 . 720 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 721 Jacobson, "RTP: A Transport Protocol for Real-Time 722 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 723 July 2003, . 725 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 726 Unique IDentifier (UUID) URN Namespace", RFC 4122, 727 DOI 10.17487/RFC4122, July 2005, 728 . 730 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 731 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 732 July 2006, . 734 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 735 (TLS) Protocol Version 1.2", RFC 5246, 736 DOI 10.17487/RFC5246, August 2008, 737 . 739 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 740 Security (DTLS) Extension to Establish Keys for the Secure 741 Real-time Transport Protocol (SRTP)", RFC 5764, 742 DOI 10.17487/RFC5764, May 2010, 743 . 745 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 746 Writing an IANA Considerations Section in RFCs", BCP 26, 747 RFC 8126, DOI 10.17487/RFC8126, June 2017, 748 . 750 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 751 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 752 May 2017, . 754 [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol 755 (SDP) Offer/Answer Considerations for Datagram Transport 756 Layer Security (DTLS) and Transport Layer Security (TLS)", 757 RFC 8842, DOI 10.17487/RFC8842, January 2021, 758 . 760 [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on 761 Uses of TLS with the Session Description Protocol (SDP)", 762 RFC 8844, DOI 10.17487/RFC8844, January 2021, 763 . 765 [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution 766 Framework for Private Media in Privacy-Enhanced RTP 767 Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, 768 January 2021, . 770 12. Informative References 772 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 773 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 774 RFC 3711, DOI 10.17487/RFC3711, March 2004, 775 . 777 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 778 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 779 January 2012, . 781 [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, 782 "Double Encryption Procedures for the Secure Real-Time 783 Transport Protocol (SRTP)", RFC 8723, 784 DOI 10.17487/RFC8723, April 2020, 785 . 787 Authors' Addresses 789 Paul E. Jones 790 Cisco Systems, Inc. 791 7025 Kit Creek Rd. 792 Research Triangle Park, North Carolina 27709 793 United States of America 795 Phone: +1 919 476 2048 796 Email: paulej@packetizer.com 797 Paul M. Ellenbogen 798 Princeton University 800 Phone: +1 206 851 2069 801 Email: pe5@cs.princeton.edu 803 Nils H. Ohlmeier 804 8x8, Inc. 806 Phone: +1 408 659 6457 807 Email: nils@ohlmeier.org