idnits 2.17.1 draft-ietf-perc-dtls-tunnel-07.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 (February 10, 2021) is 1164 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 475 -- Looks like a reference, but probably isn't: '2' on line 499 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) 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: August 14, 2021 Princeton University 6 N. Ohlmeier 7 Mozilla 8 February 10, 2021 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-ietf-perc-dtls-tunnel-07 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 August 14, 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 60 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 62 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 64 5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 65 5.3. Media Distributor Tunneling Procedures . . . . . . . . . 7 66 5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 67 5.5. Versioning Considerations . . . . . . . . . . . . . . . . 9 68 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10 70 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 13 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 11.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 An objective of Privacy-Enhanced RTP Conferencing (PERC) [RFC8871] is 82 to ensure that endpoints in a multimedia conference have access to 83 the end-to-end (E2E) and hop-by-hop (HBH) keying material used to 84 encrypt and authenticate Real-time Transport Protocol (RTP) [RFC3550] 85 packets, while the Media Distributor has access only to the hop-by- 86 hop (HBH) keying material for encryption and authentication. 88 This specification defines a tunneling protocol that enables the 89 media distributor to tunnel DTLS [RFC6347] messages between an 90 endpoint and the key distributor, thus allowing an endpoint to use 91 DTLS-SRTP [RFC5764] for establishing encryption and authentication 92 keys with the key distributor. 94 The tunnel established between the media distributor and key 95 distributor is a TLS connection that is established before any 96 messages are forwarded by the media distributor on behalf of the 97 endpoint. DTLS packets received from the endpoint are encapsulated 98 by the media distributor inside this tunnel as data to be sent to the 99 key distributor. Likewise, when the media distributor receives data 100 from the key distributor over the tunnel, it extracts the DTLS 101 message inside and forwards the DTLS message to the endpoint. In 102 this way, the DTLS association for the DTLS-SRTP procedures is 103 established between the endpoint and the key distributor, with the 104 media distributor simply forwarding packets between the two entities 105 and having no visibility into the confidential information exchanged. 107 Following the existing DTLS-SRTP procedures, the endpoint and key 108 distributor will arrive at a selected cipher and keying material, 109 which are used for HBH encryption and authentication by both the 110 endpoint and the media distributor. However, since the media 111 distributor would not have direct access to this information, the key 112 distributor explicitly shares the HBH key information with the media 113 distributor via the tunneling protocol defined in this document. 114 Additionally, the endpoint and key distributor will agree on a cipher 115 for E2E encryption and authentication. The key distributor will 116 transmit keying material to the endpoint for E2E operations, but will 117 not share that information with the media distributor. 119 By establishing this TLS tunnel between the media distributor and key 120 distributor and implementing the protocol defined in this document, 121 it is possible for the media distributor to facilitate the 122 establishment of a secure DTLS association between an endpoint and 123 the key distributor in order for the endpoint to receive E2E and HBH 124 keying material. At the same time, the key distributor can securely 125 provide the HBH keying material to the media distributor. 127 2. Conventions Used In This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119] when they 132 appear in ALL CAPS. These words may also appear in this document in 133 lower case as plain English words, absent their normative meanings. 135 3. Tunneling Concept 137 A TLS connection (tunnel) is established between the media 138 distributor and the key distributor. This tunnel is used to relay 139 DTLS messages between the endpoint and key distributor, as depicted 140 in Figure 1: 142 +-------------+ 143 | Key | 144 | Distributor | 145 +-------------+ 146 # ^ ^ # 147 # | | # <-- TLS Tunnel 148 # | | # 149 +----------+ +-------------+ +----------+ 150 | | DTLS | | DTLS | | 151 | Endpoint |<------------| Media |------------>| Endpoint | 152 | | to Key | Distributor | to Key | | 153 | | Distributor | | Distributor | | 154 +----------+ +-------------+ +----------+ 156 Figure 1: TLS Tunnel to Key Distributor 158 The three entities involved in this communication flow are the 159 endpoint, the media distributor, and the key distributor. The 160 behavior of each entity is described in Section 5. 162 The key distributor is a logical function that might might be co- 163 resident with a key management server operated by an enterprise, 164 reside in one of the endpoints participating in the conference, or 165 elsewhere that is trusted with E2E keying material. 167 4. Example Message Flows 169 This section provides an example message flow to help clarify the 170 procedures described later in this document. It is necessary that 171 the key distributor and media distributor establish a mutually 172 authenticated TLS connection for the purpose of sending tunneled 173 messages, though the complete TLS handshake for the tunnel is not 174 shown in Figure 2 since there is nothing new this document introduces 175 with regard to those procedures. 177 Once the tunnel is established, it is possible for the media 178 distributor to relay the DTLS messages between the endpoint and the 179 key distributor. Figure 2 shows a message flow wherein the endpoint 180 uses DTLS-SRTP to establish an association with the key distributor. 181 In the process, the media distributor shares its supported SRTP 182 protection profile information (see [RFC5764]) and the key 183 distributor shares HBH keying material and selected cipher with the 184 media distributor. 186 Endpoint media distributor key distributor 187 | | | 188 | |<=======================>| 189 | | TLS Connection Made | 190 | | | 191 | |========================>| 192 | | SupportedProfiles | 193 | | | 194 |------------------------>|========================>| 195 | DTLS handshake message | TunneledDtls | 196 | | | 197 | |<========================| 198 | | MediaKeys | 199 | | | 200 .... may be multiple handshake messages ... 201 | | | 202 |<------------------------|<========================| 203 | DTLS handshake message | TunneledDtls | 204 | | | 206 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 208 After the initial TLS connection has been established each of the 209 messages on the right-hand side of Figure 2 is a tunneling protocol 210 message as defined in Section 6. 212 SRTP protection profiles supported by the media distributor will be 213 sent in a "SupportedProfiles" message when the TLS tunnel is 214 initially established. The key distributor will use that information 215 to select a common profile supported by both the endpoint and the 216 media distributor to ensure that hop-by-hop operations can be 217 successfully performed. 219 As DTLS messages are received from the endpoint by the media 220 distributor, they are forwarded to the key distributor encapsulated 221 inside abbrev "TunneledDtls" message. Likewise, as "TunneledDtls" 222 messages are received by the media distributor from the key 223 distributor, the encapsulated DTLS packet is forwarded to the 224 endpoint. 226 The key distributor will provide the SRTP [RFC3711] keying material 227 to the media distributor for HBH operations via the "MediaKeys" 228 message. The media distributor will extract this keying material 229 from the "MediaKeys" message when received and use it for hop-by-hop 230 encryption and authentication. 232 5. Tunneling Procedures 234 The following sub-sections explain in detail the expected behavior of 235 the endpoint, the media distributor, and the key distributor. 237 It is important to note that the tunneling protocol described in this 238 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 239 Rather, it is a protocol that transports DTLS messages generated by 240 an endpoint or key distributor as data inside of the TLS connection 241 established between the media distributor and key distributor. 243 5.1. Endpoint Procedures 245 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 246 in order to establish the cipher and keys used for encryption and 247 authentication, with the endpoint acting as the client and the key 248 distributor acting as the server. The endpoint does not need to be 249 aware of the fact that DTLS messages it transmits toward the media 250 distributor are being tunneled to the key distributor. 252 The endpoint MUST include a unique identifier in the "tls-id" SDP 253 [RFC4566] attribute sent by the endpoint in both offer and answer 254 [RFC3264] messages as per [I-D.ietf-mmusic-dtls-sdp]. Further, the 255 endpoint MUST include this same unique identifier in the 256 "external_session_id" DTLS extension [I-D.ietf-mmusic-sdp-uks] in the 257 "ClientHello" message when establishing a DTLS association. 259 When receiving a "external_session_id" value from the key 260 distributor, the client MUST check to ensure that value matches the 261 "tls-id" value received in SDP. If the values do not match, the 262 endpoint MUST consider any received keying material to be invalid and 263 terminate the DTLS association. 265 5.2. Tunnel Establishment Procedures 267 Either the media distributor or key distributor initiates the 268 establishment of a TLS tunnel. Which entity acts as the TLS client 269 when establishing the tunnel and what event triggers the 270 establishment of the tunnel are outside the scope of this document. 271 Further, how the trust relationships are established between the key 272 distributor and media distributor are also outside the scope of this 273 document. 275 A tunnel MUST be a mutually authenticated TLS connection. 277 The media distributor or key distributor MUST establish a tunnel 278 prior to forwarding tunneled DTLS messages. Given the time-sensitive 279 nature of DTLS-SRTP procedures, a tunnel SHOULD be established prior 280 to the media distributor receiving a DTLS message from an endpoint. 282 A single tunnel MAY be used to relay DTLS messages between any number 283 of endpoints and the key distributor. 285 A media distributor MAY have more than one tunnel established between 286 itself and one or more key distributors. When multiple tunnels are 287 established, which tunnel or tunnels to use to send messages for a 288 given conference is outside the scope of this document. 290 5.3. Media Distributor Tunneling Procedures 292 The first message transmitted over the tunnel is the 293 "SupportedProfiles" (see Section 6). This message informs the key 294 distributor about which DTLS-SRTP profiles the media distributor 295 supports. This message MUST be sent each time a new tunnel 296 connection is established or, in the case of connection loss, when a 297 connection is re-established. The media distributor MUST support the 298 same list of protection profiles for the duration of any endpoint- 299 initiated DTLS association and tunnel connection. 301 The media distributor MUST assign a unique association identifier for 302 each endpoint-initiated DTLS association and include it in all 303 messages forwarded to the key distributor. The key distributor will 304 subsequently include this identifier in all messages it sends so that 305 the media distributor can map messages received via a tunnel and 306 forward those messages to the correct endpoint. The association 307 identifier MUST be randomly assigned UUID [RFC4122] value. 309 When a DTLS message is received by the media distributor from an 310 endpoint, it forwards the UDP payload portion of that message to the 311 key distributor encapsulated in a "TuneledDtls" message. The media 312 distributor is not required to forward all messages received from an 313 endpoint for a given DTLS association through the same tunnel if more 314 than one tunnel has been established between it and a key 315 distributor. 317 When a "MediaKeys" message is received, the media distributor MUST 318 extract the cipher and keying material conveyed in order to 319 subsequently perform HBH encryption and authentication operations for 320 RTP and RTCP packets sent between it and an endpoint. Since the HBH 321 keying material will be different for each endpoint, the media 322 distributor uses the association identifier included by the key 323 distributor to ensure that the HBH keying material is used with the 324 correct endpoint. 326 The media distributor MUST forward all DTLS messages received from 327 either the endpoint or the key distributor (via the "TunneledDtls" 328 message) to ensure proper communication between those two entities. 330 When the media distributor detects an endpoint has disconnected or 331 when it receives conference control messages indicating the endpoint 332 is to be disconnected, the media distributors MUST send an 333 "EndpointDisconnect" message with the association identifier assigned 334 to the endpoint to the key distributor. The media distributor SHOULD 335 take a loss of all RTP and RTCP packets as an indicator that the 336 endpoint has disconnected. The particulars of how RTP and RTCP are 337 to be used to detect an endpoint disconnect, such as timeout period, 338 is not specified. The media distributor MAY use additional 339 indicators to determine when an endpoint has disconnected. 341 5.4. Key Distributor Tunneling Procedures 343 Each TLS tunnel established between the media distributor and the key 344 distributor MUST be mutually authenticated. 346 When the media distributor relays a DTLS message from an endpoint, 347 the media distributor will include an association identifier that is 348 unique per endpoint-originated DTLS association. The association 349 identifier remains constant for the life of the DTLS association. 350 The key distributor identifies each distinct endpoint-originated DTLS 351 association by the association identifier. 353 When processing an incoming endpoint association, the key distributor 354 MUST extract the "external_session_id" value transmitted in the 355 "ClientHello" message and match that against "tls-id" value the 356 endpoint transmitted via SDP. If the values in SDP and the 357 "ClientHello" do not match, the DTLS association MUST be rejected. 359 The process through which the "tls-id" in SDP is conveyed to the key 360 distributor is outside the scope of this document. 362 The key distributor MUST correlate the certificate fingerprint and 363 "external_session_id" received from endpoint's "ClientHello" message 364 with the corresponding values received from the SDP transmitted by 365 the endpoint. It is through this correlation that the key 366 distributor can be sure to deliver the correct conference key to the 367 endpoint. 369 When sending the "ServerHello" message, the key distributor MUST 370 insert its own unique identifier in the "external_session_id" 371 extension. This value MUST also be conveyed back to the client via 372 SDP as a "tls-id" attribute. 374 The key distributor MUST encapsulate any DTLS message it sends to an 375 endpoint inside a "TunneledDtls" message (see Section 6). The key 376 distributor is not required to transmit all messages a given DTLS 377 association through the same tunnel if more than one tunnel has been 378 established between it and a media distributor. 380 The key distributor MUST use the same association identifier in 381 messages sent to an endpoint as was received in messages from that 382 endpoint. This ensures the media distributor can forward the 383 messages to the correct endpoint. 385 The key distributor extracts tunneled DTLS messages from an endpoint 386 and acts on those messages as if that endpoint had established the 387 DTLS association directly with the key distributor. The key 388 distributor is acting as the DTLS server and the endpoint is acting 389 as the DTLS client. The handling of the messages and certificates is 390 exactly the same as normal DTLS-SRTP procedures between endpoints. 392 The key distributor MUST send a "MediaKeys" message to the media 393 distributor as soon as the HBH encryption key is computed and before 394 it sends a DTLS "Finished" message to the endpoint. The "MediaKeys" 395 message includes the selected cipher (i.e. protection profile), MKI 396 [RFC3711] value (if any), SRTP master keys, and SRTP master salt 397 values. The key distributor MUST use the same association identifier 398 in the "MediaKeys" message as is used in the "TunneledDtls" messages 399 for the given endpoint. 401 The key distributor uses the certificate fingerprint of the endpoint 402 along with the unique identifier received in the 403 "external_session_id" extension to determine which conference a given 404 DTLS association is associated. 406 The key distributor MUST select a cipher that is supported by both 407 the endpoint and the media distributor to ensure proper HBH 408 operations. 410 When the DTLS association between the endpoint and the key 411 distributor is terminated, regardless of which entity initiated the 412 termination, the key distributor MUST send an "EndpointDisconnect" 413 message with the association identifier assigned to the endpoint to 414 the media distributor. 416 5.5. Versioning Considerations 418 All messages for an established tunnel MUST utilize the same version 419 value. 421 Since the media distributor sends the first message over the tunnel, 422 it effectively establishes the version of the protocol to be used. 423 If that version is not supported by the key distributor, it MUST 424 discard the message, transmit an "UnsupportedVersion" message, and 425 close the TLS connection. 427 The media distributor MUST take note of the version received in an 428 "UnsupportedVersion" message and use that version when attempting to 429 re-establish a failed tunnel connection. Note that it is not 430 necessary for the media distributor to understand the newer version 431 of the protocol to understand that the first message received is 432 "UnsupportedVersion". The media distributor can determine from the 433 first two octets received what the version number is and that the 434 message is "UnsupportedVersion". The rest of the data received, if 435 any, would be discarded and the connection closed (if not already 436 closed). 438 6. Tunneling Protocol 440 Tunneled messages are transported via the TLS tunnel as application 441 data between the media distributor and the key distributor. Tunnel 442 messages are specified using the format described in [RFC5246] 443 section 4. As in [RFC5246], all values are stored in network byte 444 (big endian) order; the uint32 represented by the hex bytes 01 02 03 445 04 is equivalent to the decimal value 16909060. 447 The protocol defines several different messages, each of which 448 containing the the following information: 450 o Protocol version 452 o Message type identifier 454 o The message body 456 Each of these messages is a "TunnelMessage" in the syntax, with a 457 message type indicating the actual content of the message body. 459 6.1. Tunnel Message Format 461 The syntax of the protocol is defined below. "TunnelMessage" defines 462 the structure of all messages sent via the tunnel protocol. That 463 structure includes a field called "msg_type" that identifies the 464 specific type of message contained within "TunnelMessage". 466 enum { 467 supported_profiles(1), 468 unsupported_version(2), 469 media_keys(3), 470 tunneled_dtls(4), 471 endpoint_disconnect(5), 472 (255) 473 } MsgType; 475 opaque uuid[16]; 477 struct { 478 MsgType msg_type; 479 uint16 length; 480 select (MsgType) { 481 case supported_profiles: SupportedProfiles; 482 case unsupported_version: UnsupportedVersion; 483 case media_keys: MediaKeys; 484 case tunneled_dtls: TunneledDtls; 485 case endpoint_disconnect: EndpointDisconnect; 486 } body; 487 } TunnelMessage; 489 The elements of "TunnelMessage" include: 491 o msg_type: the type of message contained within the structure 492 "body". 494 o length: the length in octets of the following "body" of the 495 message. 497 The "SupportedProfiles" message is defined as: 499 uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ 501 struct { 502 uint8 version; 503 SRTPProtectionProfile protection_profiles<0..2^16-1>; 504 } SupportedProfiles; 506 This message contains this single element: 508 o version: indicates the version of this protocol (0x00). 510 o protection_profiles: The list of two-octet SRTP protection profile 511 values as per [RFC5764] supported by the media distributor. 513 The "UnsupportedVersion" message is defined as follows: 515 struct { 516 uint8 highest_version; 517 } UnsupportedVersion; 519 The elements of "UnsupportedVersion" include: 521 o highest_version: indicates the highest supported protocol version. 523 The "MediaKeys" message is defined as: 525 struct { 526 uuid association_id; 527 SRTPProtectionProfile protection_profile; 528 opaque mki<0..255>; 529 opaque client_write_SRTP_master_key<1..255>; 530 opaque server_write_SRTP_master_key<1..255>; 531 opaque client_write_SRTP_master_salt<1..255>; 532 opaque server_write_SRTP_master_salt<1..255>; 533 } MediaKeys; 535 The fields are described as follows: 537 o association_id: A value that identifies a distinct DTLS 538 association between an endpoint and the key distributor. 540 o protection_profiles: The value of the two-octet SRTP protection 541 profile value as per [RFC5764] used for this DTLS association. 543 o mki: Master key identifier [RFC3711]. 545 o client_write_SRTP_master_key: The value of the SRTP master key 546 used by the client (endpoint). 548 o server_write_SRTP_master_key: The value of the SRTP master key 549 used by the server (media distributor). 551 o client_write_SRTP_master_salt: The value of the SRTP master salt 552 used by the client (endpoint). 554 o server_write_SRTP_master_salt: The value of the SRTP master salt 555 used by the server (media distributor). 557 The "TunneledDtls" message is defined as: 559 struct { 560 uuid association_id; 561 opaque dtls_message<0..2^16-1>; 562 } TunneledDtls; 563 The fields are described as follows: 565 o association_id: An value that identifies a distinct DTLS 566 association between an endpoint and the key distributor. 568 o 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 o 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 | 0x02 | Unsupported Version | 617 | 0x03 | Media Keys | 618 | 0x04 | Tunneled DTLS | 619 | 0x05 | Endpoint Disconnect | 620 +---------+------------------------------------+ 622 Table 1: Data Type Values for the DTLS Tunnel Protocol 624 The value 0x00 and all values in the range 0x06 to 0xFF are reserved. 626 The name for this registry is "Datagram Transport Layer Security 627 (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing". 629 9. Security Considerations 631 The encapsulated data is protected by the TLS connection from the 632 endpoint to key distributor, and the media distributor is merely an 633 on path entity. The media distributor does not have access to the 634 end-to-end keying material This does not introduce any additional 635 security concerns beyond a normal DTLS-SRTP association. 637 The HBH keying material is protected by the mutual authenticated TLS 638 connection between the media distributor and key distributor. The 639 key distributor MUST ensure that it only forms associations with 640 authorized media distributors or it could hand HBH keying material to 641 untrusted parties. 643 The supported profiles information sent from the media distributor to 644 the key distributor is not particularly sensitive as it only provides 645 the cryptographic algorithms supported by the media distributor. 646 Further, it is still protected by the TLS connection between the 647 media distributor and the key distributor. 649 10. Acknowledgments 651 The author would like to thank David Benham and Cullen Jennings for 652 reviewing this document and providing constructive comments. 654 11. References 655 11.1. Normative References 657 [I-D.ietf-mmusic-dtls-sdp] 658 Holmberg, C. and R. Shpount, "Session Description Protocol 659 (SDP) Offer/Answer Considerations for Datagram Transport 660 Layer Security (DTLS) and Transport Layer Security (TLS)", 661 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 662 2017. 664 [I-D.ietf-mmusic-sdp-uks] 665 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 666 uses of TLS with the Session Description Protocol (SDP)", 667 draft-ietf-mmusic-sdp-uks-07 (work in progress), August 668 2019. 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, 672 DOI 10.17487/RFC2119, March 1997, 673 . 675 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 676 with Session Description Protocol (SDP)", RFC 3264, 677 DOI 10.17487/RFC3264, June 2002, 678 . 680 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 681 Jacobson, "RTP: A Transport Protocol for Real-Time 682 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 683 July 2003, . 685 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 686 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 687 RFC 3711, DOI 10.17487/RFC3711, March 2004, 688 . 690 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 691 Unique IDentifier (UUID) URN Namespace", RFC 4122, 692 DOI 10.17487/RFC4122, July 2005, 693 . 695 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 696 (TLS) Protocol Version 1.2", RFC 5246, 697 DOI 10.17487/RFC5246, August 2008, 698 . 700 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 701 Security (DTLS) Extension to Establish Keys for the Secure 702 Real-time Transport Protocol (SRTP)", RFC 5764, 703 DOI 10.17487/RFC5764, May 2010, 704 . 706 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 707 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 708 January 2012, . 710 [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution 711 Framework for Private Media in Privacy-Enhanced RTP 712 Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, 713 January 2021, . 715 11.2. Informative References 717 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 718 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 719 July 2006, . 721 [RFC8723] Jennings, C., Jones, P., Barnes, R., and A. Roach, "Double 722 Encryption Procedures for the Secure Real-Time Transport 723 Protocol (SRTP)", RFC 8723, DOI 10.17487/RFC8723, April 724 2020, . 726 Authors' Addresses 728 Paul E. Jones 729 Cisco Systems, Inc. 730 7025 Kit Creek Rd. 731 Research Triangle Park, North Carolina 27709 732 USA 734 Phone: +1 919 476 2048 735 Email: paulej@packetizer.com 737 Paul M. Ellenbogen 738 Princeton University 740 Phone: +1 206 851 2069 741 Email: pe5@cs.princeton.edu 742 Nils H. Ohlmeier 743 Mozilla 745 Phone: +1 408 659 6457 746 Email: nils@ohlmeier.org