idnits 2.17.1 draft-ietf-perc-dtls-tunnel-11.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 (25 October 2021) is 912 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 489 -- Looks like a reference, but probably isn't: '2' on line 518 Summary: 0 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: 28 April 2022 Princeton University 6 N. Ohlmeier 7 8x8, Inc. 8 25 October 2021 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-ietf-perc-dtls-tunnel-11 14 Abstract 16 This document defines a protocol for tunneling DTLS traffic in 17 multimedia conferences that enables a Media Distributor to facilitate 18 key exchange between an endpoint in a conference and the Key 19 Distributor. The protocol is designed to ensure that the keying 20 material used for hop-by-hop encryption and authentication is 21 accessible to the Media Distributor, while the keying material used 22 for end-to-end encryption and authentication is inaccessible to the 23 Media Distributor. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 28 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . 4 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. Media Distributor Tunneling Procedures . . . . . . . . . 7 66 5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 67 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 10 68 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. TunnelMessage Structure . . . . . . . . . . . . . . . . . 11 70 6.2. SupportedProfiles Message . . . . . . . . . . . . . . . . 11 71 6.3. UnsupportedVersion Message . . . . . . . . . . . . . . . 12 72 6.4. MediaKeys Message . . . . . . . . . . . . . . . . . . . . 12 73 6.5. TunneledDtls Message . . . . . . . . . . . . . . . . . . 13 74 6.6. EndpointDisconnect Message . . . . . . . . . . . . . . . 13 75 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 79 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 80 12. Informative References . . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is 86 to ensure that endpoints in a multimedia conference have access to 87 the end-to-end (E2E) and hop-by-hop (HBH) keying material used to 88 encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] 89 packets, while the Media Distributor has access only to the HBH 90 keying material for encryption and authentication. 92 This specification defines a tunneling protocol that enables the 93 Media Distributor to tunnel DTLS [I-D.ietf-tls-dtls13] messages 94 between an endpoint and a Key Distributor, thus allowing an endpoint 95 to use DTLS-SRTP [RFC5764] for establishing encryption and 96 authentication keys with the Key Distributor. 98 The tunnel established between the Media Distributor and Key 99 Distributor is a TLS [RFC8446] connection that is established before 100 any messages are forwarded by the Media Distributor on behalf of 101 endpoints. DTLS packets received from an endpoint are encapsulated 102 by the Media Distributor inside this tunnel as data to be sent to the 103 Key Distributor. Likewise, when the Media Distributor receives data 104 from the Key Distributor over the tunnel, it extracts the DTLS 105 message inside and forwards the DTLS message to the endpoint. In 106 this way, the DTLS association for the DTLS-SRTP procedures is 107 established between an endpoint and the Key Distributor, with the 108 Media Distributor forwarding DTLS messages between the two entities 109 via the established tunnel to the Key Distributor and having no 110 visibility into the confidential information exchanged. 112 Following the existing DTLS-SRTP procedures, the endpoint and Key 113 Distributor will arrive at a selected cipher and keying material, 114 which are used for HBH encryption and authentication by both the 115 endpoint and the Media Distributor. However, since the Media 116 Distributor would not have direct access to this information, the Key 117 Distributor explicitly shares the HBH key information with the Media 118 Distributor via the tunneling protocol defined in this document. 119 Additionally, the endpoint and Key Distributor will agree on a cipher 120 for E2E encryption and authentication. The Key Distributor will 121 transmit keying material to the endpoint for E2E operations, but will 122 not share that information with the Media Distributor. 124 By establishing this TLS tunnel between the Media Distributor and Key 125 Distributor and implementing the protocol defined in this document, 126 it is possible for the Media Distributor to facilitate the 127 establishment of a secure DTLS association between an endpoint and 128 the Key Distributor in order for the endpoint to generate E2E and HBH 129 keying material. At the same time, the Key Distributor can securely 130 provide the HBH keying material to the Media Distributor. 132 2. Conventions Used In This Document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 This document uses the terms "endpoint", "Media Distributor", and 141 "Key Distributor" defined in [RFC8871]. 143 3. Tunneling Concept 145 A TLS connection (tunnel) is established between the Media 146 Distributor and the Key Distributor. This tunnel is used to relay 147 DTLS messages between the endpoint and Key Distributor, as depicted 148 in Figure 1: 150 +-------------+ 151 | Key | 152 | Distributor | 153 +-------------+ 154 # ^ ^ # 155 # | | # <-- TLS Tunnel 156 # | | # 157 +----------+ +-------------+ +----------+ 158 | | DTLS | | DTLS | | 159 | Endpoint |<------------| Media |------------>| Endpoint | 160 | | to Key | Distributor | to Key | | 161 | | Distributor | | Distributor | | 162 +----------+ +-------------+ +----------+ 164 Figure 1: TLS Tunnel to Key Distributor 166 The three entities involved in this communication flow are the 167 endpoint, the Media Distributor, and the Key Distributor. The 168 behavior of each entity is described in Section 5. 170 The Key Distributor is a logical function that might be co-resident 171 with a key management server operated by an enterprise, reside in one 172 of the endpoints participating in the conference, or elsewhere that 173 is trusted with E2E keying material. 175 4. Example Message Flows 177 This section provides an example message flow to help clarify the 178 procedures described later in this document. It is necessary that 179 the Key Distributor and Media Distributor establish a mutually 180 authenticated TLS connection for the purpose of sending tunneled 181 messages, though the complete TLS handshake for the tunnel is not 182 shown in Figure 2 since there is nothing new this document introduces 183 with regard to those procedures. 185 Once the tunnel is established, it is possible for the Media 186 Distributor to relay the DTLS messages between the endpoint and the 187 Key Distributor. Figure 2 shows a message flow wherein the endpoint 188 uses DTLS-SRTP to establish an association with the Key Distributor. 189 In the process, the Media Distributor shares its supported SRTP 190 protection profile information (see [RFC5764]) and the Key 191 Distributor shares HBH keying material and selected cipher with the 192 Media Distributor. 194 Endpoint Media Distributor Key Distributor 195 | | | 196 | |<=======================>| 197 | | TLS Connection Made | 198 | | | 199 | |========================>| 200 | | SupportedProfiles | 201 | | | 202 |------------------------>|========================>| 203 | DTLS handshake message | TunneledDtls | 204 | | | 205 .... may be multiple handshake messages ... 206 | | | 207 |<------------------------|<========================| 208 | DTLS handshake message | TunneledDtls | 209 | | | 210 | | | 211 | |<========================| 212 | | MediaKeys | 214 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 216 After the initial TLS connection has been established each of the 217 messages on the right-hand side of Figure 2 is a tunneling protocol 218 message as defined in Section 6. 220 SRTP protection profiles supported by the Media Distributor will be 221 sent in a "SupportedProfiles" message when the TLS tunnel is 222 initially established. The Key Distributor will use that information 223 to select a common profile supported by both the endpoint and the 224 Media Distributor to ensure that HBH operations can be successfully 225 performed. 227 As DTLS messages are received from the endpoint by the Media 228 Distributor, they are forwarded to the Key Distributor encapsulated 229 inside a "TunneledDtls" message. Likewise, as "TunneledDtls" 230 messages are received by the Media Distributor from the Key 231 Distributor, the encapsulated DTLS packet is forwarded to the 232 endpoint. 234 The Key Distributor will provide the SRTP [RFC3711] keying material 235 to the Media Distributor for HBH operations via the "MediaKeys" 236 message. The Media Distributor will extract this keying material 237 from the "MediaKeys" message when received and use it for HBH 238 encryption and authentication. 240 5. Tunneling Procedures 242 The following sub-sections explain in detail the expected behavior of 243 the endpoint, the Media Distributor, and the Key Distributor. 245 It is important to note that the tunneling protocol described in this 246 document is not an extension to TLS or DTLS. Rather, it is a 247 protocol that transports DTLS messages generated by an endpoint or 248 Key Distributor as data inside of the TLS connection established 249 between the Media Distributor and Key Distributor. 251 5.1. Endpoint Procedures 253 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 254 in order to establish the cipher and keys used for encryption and 255 authentication, with the endpoint acting as the client and the Key 256 Distributor acting as the server. The endpoint does not need to be 257 aware of the fact that DTLS messages it transmits toward the Media 258 Distributor are being tunneled to the Key Distributor. 260 The endpoint MUST include a unique identifier in the "tls-id" SDP 261 [RFC8866] attribute in all offer and answer messages [RFC3264] that 262 it generates as per [RFC8842]. Further, the endpoint MUST include 263 this same unique identifier in the "external_session_id" extension 264 [RFC8844] in the "ClientHello" message when establishing a DTLS 265 association. 267 When receiving a "external_session_id" value from the Key 268 Distributor, the client MUST check to ensure that value matches the 269 "tls-id" value received in SDP. If the values do not match, the 270 endpoint MUST consider any received keying material to be invalid and 271 terminate the DTLS association. 273 5.2. Tunnel Establishment Procedures 275 Either the Media Distributor or Key Distributor initiates the 276 establishment of a TLS tunnel. Which entity acts as the TLS client 277 when establishing the tunnel and what event triggers the 278 establishment of the tunnel are outside the scope of this document. 279 Further, how the trust relationships are established between the Key 280 Distributor and Media Distributor are also outside the scope of this 281 document. 283 A tunnel MUST be a mutually authenticated TLS connection. 285 The Media Distributor or Key Distributor MUST establish a tunnel 286 prior to forwarding tunneled DTLS messages. Given the time-sensitive 287 nature of DTLS-SRTP procedures, a tunnel SHOULD be established prior 288 to the Media Distributor receiving a DTLS message from an endpoint. 290 A single tunnel MAY be used to relay DTLS messages between any number 291 of endpoints and the Key Distributor. 293 A Media Distributor MAY have more than one tunnel established between 294 itself and one or more Key Distributors. When multiple tunnels are 295 established, which tunnel or tunnels to use to send messages for a 296 given conference is outside the scope of this document. 298 5.3. Media Distributor Tunneling Procedures 300 The first message transmitted over the tunnel is the 301 "SupportedProfiles" (see Section 6). This message informs the Key 302 Distributor about which DTLS-SRTP profiles the Media Distributor 303 supports. This message MUST be sent each time a new tunnel 304 connection is established or, in the case of connection loss, when a 305 connection is re-established. The Media Distributor MUST support the 306 same list of protection profiles for the duration of any endpoint- 307 initiated DTLS association and tunnel connection. 309 The Media Distributor MUST assign a unique association identifier for 310 each endpoint-initiated DTLS association and include it in all 311 messages forwarded to the Key Distributor. The Key Distributor will 312 subsequently include this identifier in all messages it sends so that 313 the Media Distributor can map messages received via a tunnel and 314 forward those messages to the correct endpoint. The association 315 identifier MUST be randomly assigned UUID value as described 316 Section 4.4 of [RFC4122]. 318 When a DTLS message is received by the Media Distributor from an 319 endpoint, it forwards the UDP payload portion of that message to the 320 Key Distributor encapsulated in a "TuneledDtls" message. The Media 321 Distributor is not required to forward all messages received from an 322 endpoint for a given DTLS association through the same tunnel if more 323 than one tunnel has been established between it and a Key 324 Distributor. 326 When a "MediaKeys" message is received, the Media Distributor MUST 327 extract the cipher and keying material conveyed in order to 328 subsequently perform HBH encryption and authentication operations for 329 RTP and RTCP packets sent between it and an endpoint. Since the HBH 330 keying material will be different for each endpoint, the Media 331 Distributor uses the association identifier included by the Key 332 Distributor to ensure that the HBH keying material is used with the 333 correct endpoint. 335 The Media Distributor MUST forward all DTLS messages received from 336 either the endpoint or the Key Distributor (via the "TunneledDtls" 337 message) to ensure proper communication between those two entities. 339 When the Media Distributor detects an endpoint has disconnected or 340 when it receives conference control messages indicating the endpoint 341 is to be disconnected, the Media Distributors MUST send an 342 "EndpointDisconnect" message with the association identifier assigned 343 to the endpoint to the Key Distributor. The Media Distributor SHOULD 344 take a loss of all RTP and RTCP packets as an indicator that the 345 endpoint has disconnected. The particulars of how RTP and RTCP are 346 to be used to detect an endpoint disconnect, such as timeout period, 347 is not specified. The Media Distributor MAY use additional 348 indicators to determine when an endpoint has disconnected. 350 5.4. Key Distributor Tunneling Procedures 352 Each TLS tunnel established between the Media Distributor and the Key 353 Distributor MUST be mutually authenticated. 355 When the Media Distributor relays a DTLS message from an endpoint, 356 the Media Distributor will include an association identifier that is 357 unique per endpoint-originated DTLS association. The association 358 identifier remains constant for the life of the DTLS association. 359 The Key Distributor identifies each distinct endpoint-originated DTLS 360 association by the association identifier. 362 When processing an incoming endpoint association, the Key Distributor 363 MUST extract the "external_session_id" value transmitted in the 364 "ClientHello" message and match that against the "tls-id" value the 365 endpoint transmitted via SDP. If the values in SDP and the 366 "ClientHello" do not match, the DTLS association MUST be rejected. 368 The process through which the "tls-id" in SDP is conveyed to the Key 369 Distributor is outside the scope of this document. 371 The Key Distributor MUST match the certificate fingerprint and 372 "external_session_id" [RFC8844] received from endpoint via DTLS with 373 the expected fingerprint [RFC8122] and "tls-id" [RFC8842] values 374 received via SDP. It is through this process that the Key 375 Distributor can be sure to deliver the correct conference key to the 376 endpoint. 378 The Key Distributor MUST report its own unique identifier in the 379 "external_session_id" extension. This extension is sent in the 380 "EncryptedExtensions" message in DTLS 1.3, and the "ServerHello" in 381 previous DTLS versions. This value MUST also be conveyed back to the 382 client via SDP as a "tls-id" attribute. 384 The Key Distributor MUST encapsulate any DTLS message it sends to an 385 endpoint inside a "TunneledDtls" message (see Section 6). The Key 386 Distributor is not required to transmit all messages for a given DTLS 387 association through the same tunnel if more than one tunnel has been 388 established between it and the Media Distributor. 390 The Key Distributor MUST use the same association identifier in 391 messages sent to an endpoint as was received in messages from that 392 endpoint. This ensures the Media Distributor can forward the 393 messages to the correct endpoint. 395 The Key Distributor extracts tunneled DTLS messages from an endpoint 396 and acts on those messages as if that endpoint had established the 397 DTLS association directly with the Key Distributor. The Key 398 Distributor is acting as the DTLS server and the endpoint is acting 399 as the DTLS client. The handling of the messages and certificates is 400 exactly the same as normal DTLS-SRTP procedures between endpoints. 402 The Key Distributor MUST send a "MediaKeys" message to the Media 403 Distributor immediately after the DTLS handshake completes. The 404 "MediaKeys" message includes the selected cipher (i.e. protection 405 profile), MKI [RFC3711] value (if any), HBH SRTP master keys, and 406 SRTP master salt values. The Key Distributor MUST use the same 407 association identifier in the "MediaKeys" message as is used in the 408 "TunneledDtls" messages for the given endpoint. 410 There are presently two SRTP protection profiles defined for PERC, 411 namely "DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and 412 "DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723]. As [RFC8723] 413 explains in Section 5.2, the Media Distributor is only given the SRTP 414 master key for HBH operations. As such, the SRTP master key length 415 advertised in the "MediaKeys" message is half the length of the key 416 normally associated with selected "double" protection profile. 418 The Key Distributor uses the certificate fingerprint of the endpoint 419 along with the unique identifier received in the 420 "external_session_id" extension to determine which conference a given 421 DTLS association is associated. 423 The Key Distributor MUST select a cipher that is supported itself, 424 the endpoint, and the Media Distributor to ensure proper HBH 425 operations. 427 When the DTLS association between the endpoint and the Key 428 Distributor is terminated, regardless of which entity initiated the 429 termination, the Key Distributor MUST send an "EndpointDisconnect" 430 message with the association identifier assigned to the endpoint to 431 the Media Distributor. 433 5.5. Versioning Considerations 435 Since the Media Distributor sends the first message over the tunnel, 436 it effectively establishes the version of the protocol to be used. 437 If that version is not supported by the Key Distributor, the Key 438 Distributor MUST transmit an "UnsupportedVersion" message containing 439 the highest version number supported, and close the TLS connection. 441 The Media Distributor MUST take note of the version received in an 442 "UnsupportedVersion" message and use that version when attempting to 443 re-establish a failed tunnel connection. Note that it is not 444 necessary for the Media Distributor to understand the newer version 445 of the protocol to understand that the first message received is 446 "UnsupportedVersion". The Media Distributor can determine from the 447 first four octets received what the version number is and that the 448 message is "UnsupportedVersion". The rest of the data received, if 449 any, would be discarded and the connection closed (if not already 450 closed). 452 6. Tunneling Protocol 454 Tunneled messages are transported via the TLS tunnel as application 455 data between the Media Distributor and the Key Distributor. Tunnel 456 messages are specified using the format described in [RFC8446] 457 section 3. As in [RFC8446], all values are stored in network byte 458 (big endian) order; the uint32 represented by the hex bytes 01 02 03 459 04 is equivalent to the decimal value 16909060. 461 This protocol defines several different messages, each of which 462 contains the following information: 464 * Message type identifier 466 * Message body length 468 * The message body 470 Each of the tunnel messages is a "TunnelMessage" structure with the 471 message type indicating the actual content of the message body. 473 6.1. TunnelMessage Structure 475 The "TunnelMessage" defines the structure of all messages sent via 476 the tunnel protocol. That structure includes a field called 477 "msg_type" that identifies the specific type of message contained 478 within "TunnelMessage". 480 enum { 481 supported_profiles(1), 482 unsupported_version(2), 483 media_keys(3), 484 tunneled_dtls(4), 485 endpoint_disconnect(5), 486 (255) 487 } MsgType; 489 opaque uuid[16]; 491 struct { 492 MsgType msg_type; 493 uint16 length; 494 select (MsgType) { 495 case supported_profiles: SupportedProfiles; 496 case unsupported_version: UnsupportedVersion; 497 case media_keys: MediaKeys; 498 case tunneled_dtls: TunneledDtls; 499 case endpoint_disconnect: EndpointDisconnect; 500 } body; 501 } TunnelMessage; 503 The elements of "TunnelMessage" include: 505 * "msg_type": the type of message contained within the structure 506 "body". 508 * "length": the length in octets of the following "body" of the 509 message. 511 * "body": the actual message being conveyed within this 512 "TunnelMessage" structure. 514 6.2. SupportedProfiles Message 516 The "SupportedProfiles" message is defined as: 518 uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ 520 struct { 521 uint8 version; 522 SRTPProtectionProfile protection_profiles<2..2^16-1>; 523 } SupportedProfiles; 525 This message contains this single element: 527 * "version": This document specifies version 0x00. 529 * "protection_profiles": The list of two-octet SRTP protection 530 profile values as per [RFC5764] supported by the Media 531 Distributor. 533 6.3. UnsupportedVersion Message 535 The "UnsupportedVersion" message is defined as follows: 537 struct { 538 uint8 highest_version; 539 } UnsupportedVersion; 541 The elements of "UnsupportedVersion" include: 543 * "highest_version": indicates the highest version of the protocol 544 supported by the Key Distributor. 546 6.4. MediaKeys Message 548 The "MediaKeys" message is defined as: 550 struct { 551 uuid association_id; 552 SRTPProtectionProfile protection_profile; 553 opaque mki<0..255>; 554 opaque client_write_SRTP_master_key<1..255>; 555 opaque server_write_SRTP_master_key<1..255>; 556 opaque client_write_SRTP_master_salt<1..255>; 557 opaque server_write_SRTP_master_salt<1..255>; 558 } MediaKeys; 560 The fields are described as follows: 562 * "association_id": A value that identifies a distinct DTLS 563 association between an endpoint and the Key Distributor. 565 * "protection_profiles": The value of the two-octet SRTP protection 566 profile value as per [RFC5764] used for this DTLS association. 568 * "mki": Master key identifier [RFC3711]. A zero-length field 569 indicates that no MKI value is present. 571 * "client_write_SRTP_master_key": The value of the SRTP master key 572 used by the client (endpoint). 574 * "server_write_SRTP_master_key": The value of the SRTP master key 575 used by the server (Media Distributor). 577 * "client_write_SRTP_master_salt": The value of the SRTP master salt 578 used by the client (endpoint). 580 * "server_write_SRTP_master_salt": The value of the SRTP master salt 581 used by the server (Media Distributor). 583 6.5. TunneledDtls Message 585 The "TunneledDtls" message is defined as: 587 struct { 588 uuid association_id; 589 opaque dtls_message<1..2^16-1>; 590 } TunneledDtls; 592 The fields are described as follows: 594 * "association_id": A value that identifies a distinct DTLS 595 association between an endpoint and the Key Distributor. 597 * "dtls_message": the content of the DTLS message received by the 598 endpoint or to be sent to the endpoint. This includes one or more 599 complete DTLS records. 601 6.6. EndpointDisconnect Message 603 The "EndpointDisconnect" message is defined as: 605 struct { 606 uuid association_id; 607 } EndpointDisconnect; 609 The fields are described as follows: 611 * "association_id": An value that identifies a distinct DTLS 612 association between an endpoint and the Key Distributor. 614 7. Example Binary Encoding 616 The "TunnelMessage" is encoded in binary following the procedures 617 specified in [RFC8446]. This section provides an example of what the 618 bits on the wire would look like for the "SupportedProfiles" message 619 that advertises support for both 620 "DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM" and 621 "DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM" [RFC8723]. 623 TunnelMessage: 624 message_type: 0x01 625 length: 0x0007 626 SupportedProfiles: 627 version: 0x00 628 protection_profiles: 0x0004 (length) 629 0x0009000A (value) 631 Thus, the encoding on the wire presented here in network bytes order 632 would be this stream of octets: 634 0x0100070000040009000A 636 8. IANA Considerations 638 This document establishes a new registry to contain message type 639 values used in the DTLS Tunnel protocol. These message type values 640 are a single octet in length. This document defines the values shown 641 in Table 1 below, leaving the balance of possible values reserved for 642 future specifications: 644 +=========+====================================+ 645 | MsgType | Description | 646 +=========+====================================+ 647 | 0x01 | Supported SRTP Protection Profiles | 648 +---------+------------------------------------+ 649 | 0x02 | Unsupported Version | 650 +---------+------------------------------------+ 651 | 0x03 | Media Keys | 652 +---------+------------------------------------+ 653 | 0x04 | Tunneled DTLS | 654 +---------+------------------------------------+ 655 | 0x05 | Endpoint Disconnect | 656 +---------+------------------------------------+ 658 Table 1: Message Type Values for the DTLS 659 Tunnel Protocol 661 The value 0x00 is reserved and all values in the range 0x06 to 0xFF 662 are available for allocation. The procedures for updating this table 663 are those defined as "IETF Review" in section 4.8 of [RFC8126]. 665 The name for this registry is "Datagram Transport Layer Security 666 (DTLS) Tunnel Protocol Message Types for Privacy Enhanced 667 Conferencing". 669 9. Security Considerations 671 Since the procedures in this document relies on TLS [RFC8446] for 672 transport security, the security considerations for TLS should be 673 reviewed when implementing the protocol defined in this document. 675 While the tunneling protocol defined in this document does not use 676 DTLS-SRTP [RFC5764] directly, it does convey and negotiate some of 677 the same information (e.g., protection profile data). As such, a 678 review of the security considerations found in that document may be 679 useful. 681 This document describes a means of securely exchanging keying 682 material and cryptographic transforms for both E2E and HBH encryption 683 and authentication of media between an endpoint and a Key Distributor 684 via a Media Distributor. Additionally, the procedures result in 685 delivering HBH information to the intermediary Media Distributor. 686 The Key Distributor and endpoint are the only two entities with 687 access to both the E2E and HBH keys, while the Media Distributor has 688 access to only HBH information. Section 8.2 of [RFC8871] enumerates 689 various attacks against which one must guard when implementing a 690 Media Distributor and are important to note. 692 A requirement in this document is that a TLS connection between the 693 Media Distributor and the Key Distributor be mutually authenticated. 694 The reason for this requirement is to ensure that only an authorized 695 Media Distributor receives the HBH keying material. If an 696 unauthorized Media Distributor gains access to the HBH keying 697 material, it can easily cause service degradation or denial by 698 transmitting HBH-valid packets that ultimately fail E2E 699 authentication or replay protection checks (see Section 3.3.2 of 700 [RFC3711]). Even if service does not appear degraded in any way, 701 transmitting and processing bogus packets are a waste of both 702 computational and network resources. 704 The procedures defined in this document assume that the Media 705 Distributor will properly convey DTLS messages between the endpoint 706 and Key Distributor. Should it fail in that responsibility by 707 forwarding DTLS messages from endpoint A advertised as being from 708 endpoint B, this will result in a failure at the DTLS layer those 709 DTLS sessions. This could be an additional attack vector that Key 710 Distributor implementations should consider. 712 While E2E keying material passes through the Media Distributor via 713 the protocol defined in this document, the Media Distributor has no 714 means of gaining access to that information and therefore cannot 715 affect the E2E media processing function in the endpoint except to 716 present it with invalid or replayed data. That said, any entity 717 along the path that interferes with the DTLS exchange between the 718 endpoint and the Key Distributor, including a malicious Media 719 Distributor that is not properly authorized, could prevent an 720 endpoint from properly communicating with the Key Distributor and, 721 therefore, prevent successful conference participation. 723 It is worth noting that a compromised Media Distributor can convey 724 information to an adversary such as participant IP addresses, 725 negotiates protection profiles, or other metadata. While [RFC8871] 726 explains that a malicious or compromised Media Distributor can 727 disrupt communications, an additional attack vector introduced by 728 this protocol is the potential disruption of DTLS negotiation or 729 premature removal of a participant from a conference by sending an 730 "EndpointDisconnect" disconnect message to the Key Distributor. 732 The Key Distributor should be aware of the possibility that a 733 malicious Media Distributor might transmit an "EndpointDisconnect" 734 message to the Key Distributor when the endpoint is, in fact, still 735 connected. 737 While the Security Considerations section of [RFC8871] describes 738 various attacks one needs to consider with respect to the Key 739 Distributor and denial-of-service, use of this protocol introduces 740 another possible attack vector. Consider the case where a malicious 741 endpoint sends unsolicited DTLS-SRTP messages to a Media Distributor. 742 The Media Distributor will normally forward those messages to the Key 743 Distributor and, if found invalid, such messages only serve to 744 consume resources on both the Media Distributor and Key Distributor. 746 10. Acknowledgments 748 The author would like to thank David Benham and Cullen Jennings for 749 reviewing this document and providing constructive comments. 751 11. Normative References 753 [I-D.ietf-tls-dtls13] 754 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 755 Datagram Transport Layer Security (DTLS) Protocol Version 756 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 757 dtls13-43, 30 April 2021, 758 . 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, 762 DOI 10.17487/RFC2119, March 1997, 763 . 765 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 766 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 767 RFC 3711, DOI 10.17487/RFC3711, March 2004, 768 . 770 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 771 Unique IDentifier (UUID) URN Namespace", RFC 4122, 772 DOI 10.17487/RFC4122, July 2005, 773 . 775 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 776 Security (DTLS) Extension to Establish Keys for the Secure 777 Real-time Transport Protocol (SRTP)", RFC 5764, 778 DOI 10.17487/RFC5764, May 2010, 779 . 781 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 782 Transport over the Transport Layer Security (TLS) Protocol 783 in the Session Description Protocol (SDP)", RFC 8122, 784 DOI 10.17487/RFC8122, March 2017, 785 . 787 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 788 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 789 May 2017, . 791 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 792 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 793 . 795 [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, 796 "Double Encryption Procedures for the Secure Real-Time 797 Transport Protocol (SRTP)", RFC 8723, 798 DOI 10.17487/RFC8723, April 2020, 799 . 801 [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol 802 (SDP) Offer/Answer Considerations for Datagram Transport 803 Layer Security (DTLS) and Transport Layer Security (TLS)", 804 RFC 8842, DOI 10.17487/RFC8842, January 2021, 805 . 807 [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on 808 Uses of TLS with the Session Description Protocol (SDP)", 809 RFC 8844, DOI 10.17487/RFC8844, January 2021, 810 . 812 [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution 813 Framework for Private Media in Privacy-Enhanced RTP 814 Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, 815 January 2021, . 817 12. Informative References 819 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 820 with Session Description Protocol (SDP)", RFC 3264, 821 DOI 10.17487/RFC3264, June 2002, 822 . 824 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 825 Jacobson, "RTP: A Transport Protocol for Real-Time 826 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 827 July 2003, . 829 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 830 Writing an IANA Considerations Section in RFCs", BCP 26, 831 RFC 8126, DOI 10.17487/RFC8126, June 2017, 832 . 834 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 835 Session Description Protocol", RFC 8866, 836 DOI 10.17487/RFC8866, January 2021, 837 . 839 Authors' Addresses 841 Paul E. Jones 842 Cisco Systems, Inc. 843 7025 Kit Creek Rd. 844 Research Triangle Park, North Carolina 27709 845 United States of America 847 Phone: +1 919 476 2048 848 Email: paulej@packetizer.com 849 Paul M. Ellenbogen 850 Princeton University 852 Phone: +1 206 851 2069 853 Email: pe5@cs.princeton.edu 855 Nils H. Ohlmeier 856 8x8, Inc. 858 Phone: +1 408 659 6457 859 Email: nils@ohlmeier.org