idnits 2.17.1 draft-ietf-perc-dtls-tunnel-05.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 (April 17, 2019) is 1835 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 474 -- Looks like a reference, but probably isn't: '2' on line 498 ** Downref: Normative reference to an Informational draft: draft-thomson-mmusic-sdp-uks (ref. 'I-D.thomson-mmusic-sdp-uks') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-10 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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: Standards Track P. Ellenbogen 5 Expires: October 19, 2019 Princeton University 6 N. Ohlmeier 7 Mozilla 8 April 17, 2019 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-ietf-perc-dtls-tunnel-05 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 October 19, 2019. 41 Copyright Notice 43 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 14 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 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) is to ensure 82 that endpoints in a multimedia conference have access to the end-to- 83 end (E2E) and hop-by-hop (HBH) keying material used to encrypt and 84 authenticate Real-time Transport Protocol (RTP) [RFC3550] packets, 85 while the Media Distributor has access only to the hop-by-hop (HBH) 86 keying material for encryption and authentication. 88 This specification defines a tunneling protocol that enables the 89 media distributor to tunnel DTLS [RFC6347] messages between an 90 endpoint and the key distributor, thus allowing an endpoint to use 91 DTLS-SRTP [RFC5764] for establishing encryption and authentication 92 keys with the key distributor. 94 The tunnel established between the media distributor and key 95 distributor is a TLS connection that is established before any 96 messages are forwarded by the media distributor on behalf of the 97 endpoint. DTLS packets received from the endpoint are encapsulated 98 by the media distributor inside this tunnel as data to be sent to the 99 key distributor. Likewise, when the media distributor receives data 100 from the key distributor over the tunnel, it extracts the DTLS 101 message inside and forwards the DTLS message to the endpoint. In 102 this way, the DTLS association for the DTLS-SRTP procedures is 103 established between the endpoint and the key distributor, with the 104 media distributor simply forwarding packets between the two entities 105 and having no visibility into the confidential information exchanged. 107 Following the existing DTLS-SRTP procedures, the endpoint and key 108 distributor will arrive at a selected cipher and keying material, 109 which are used for HBH encryption and authentication by both the 110 endpoint and the media distributor. However, since the media 111 distributor would not have direct access to this information, the key 112 distributor explicitly shares the HBH key information with the media 113 distributor via the tunneling protocol defined in this document. 114 Additionally, the endpoint and key distributor will agree on a cipher 115 for E2E encryption and authentication. The key distributor will 116 transmit keying material to the endpoint for E2E operations, but will 117 not share that information with the media distributor. 119 By establishing this TLS tunnel between the media distributor and key 120 distributor and implementing the protocol defined in this document, 121 it is possible for the media distributor to facilitate the 122 establishment of a secure DTLS association between an endpoint and 123 the key distributor in order for the endpoint to receive E2E and HBH 124 keying material. At the same time, the key distributor can securely 125 provide the HBH keying material to the media distributor. 127 2. Conventions Used In This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119] when they 132 appear in ALL CAPS. These words may also appear in this document in 133 lower case as plain English words, absent their normative meanings. 135 3. Tunneling Concept 137 A TLS connection (tunnel) is established between the media 138 distributor and the key distributor. This tunnel is used to relay 139 DTLS messages between the endpoint and key distributor, as depicted 140 in Figure 1: 142 +-------------+ 143 | Key | 144 | Distributor | 145 +-------------+ 146 # ^ ^ # 147 # | | # <-- TLS Tunnel 148 # | | # 149 +----------+ +-------------+ +----------+ 150 | | DTLS | | DTLS | | 151 | Endpoint |<------------| Media |------------>| Endpoint | 152 | | to Key | Distributor | to Key | | 153 | | Distributor | | Distributor | | 154 +----------+ +-------------+ +----------+ 156 Figure 1: TLS Tunnel to Key Distributor 158 The three entities involved in this communication flow are the 159 endpoint, the media distributor, and the key distributor. The 160 behavior of each entity is described in Section 5. 162 The key distributor is a logical function that might might be co- 163 resident with a key management server operated by an enterprise, 164 reside in one of the endpoints participating in the conference, or 165 elsewhere that is trusted with E2E keying material. 167 4. Example Message Flows 169 This section provides an example message flow to help clarify the 170 procedures described later in this document. It is necessary that 171 the key distributor and media distributor establish a mutually 172 authenticated TLS connection for the purpose of sending tunneled 173 messages, though the complete TLS handshake for the tunnel is not 174 shown in Figure 2 since there is nothing new this document introduces 175 with regard to those procedures. 177 Once the tunnel is established, it is possible for the media 178 distributor to relay the DTLS messages between the endpoint and the 179 key distributor. Figure 2 shows a message flow wherein the endpoint 180 uses DTLS-SRTP to establish an association with the key distributor. 181 In the process, the media distributor shares its supported SRTP 182 protection profile information (see [RFC5764]) and the key 183 distributor shares HBH keying material and selected cipher with the 184 media distributor. 186 Endpoint media distributor key distributor 187 | | | 188 | |<=======================>| 189 | | TLS Connection Made | 190 | | | 191 | |========================>| 192 | | SupportedProfiles | 193 | | | 194 |------------------------>|========================>| 195 | DTLS handshake message | TunneledDtls | 196 | | | 197 | |<========================| 198 | | MediaKeys | 199 | | | 200 .... may be multiple handshake messages ... 201 | | | 202 |<------------------------|<========================| 203 | DTLS handshake message | TunneledDtls | 204 | | | 206 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 208 After the initial TLS connection has been established each of the 209 messages on the right-hand side of Figure 2 is a tunneling protocol 210 message as defined in Section Section 6. 212 SRTP protection profiles supported by the media distributor will be 213 sent in a "SupportedProfiles" message when the TLS tunnel is 214 initially established. The key distributor will use that information 215 to select a common profile supported by both the endpoint and the 216 media distributor to ensure that hop-by-hop operations can be 217 successfully performed. 219 As DTLS messages are received from the endpoint by the media 220 distributor, they are forwarded to the key distributor encapsulated 221 inside abbrev "TunneledDtls" message. Likewise, as "TunneledDtls" 222 messages are received by the media distributor from the key 223 distributor, the encapsulated DTLS packet is forwarded to the 224 endpoint. 226 The key distributor will provide the SRTP [RFC3711] keying material 227 to the media distributor for HBH operations via the "MediaKeys" 228 message. The media distributor will extract this keying material 229 from the "MediaKeys" message when received and use it for hop-by-hop 230 encryption and authentication. 232 5. Tunneling Procedures 234 The following sub-sections explain in detail the expected behavior of 235 the endpoint, the media distributor, and the key distributor. 237 It is important to note that the tunneling protocol described in this 238 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 239 Rather, it is a protocol that transports DTLS messages generated by 240 an endpoint or key distributor as data inside of the TLS connection 241 established between the media distributor and key distributor. 243 5.1. Endpoint Procedures 245 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 246 in order to establish the cipher and keys used for encryption and 247 authentication, with the endpoint acting as the client and the key 248 distributor acting as the server. The endpoint does not need to be 249 aware of the fact that DTLS messages it transmits toward the media 250 distributor are being tunneled to the key distributor. 252 The endpoint MUST include the "sdp_tls_id" DTLS extension 253 [I-D.thomson-mmusic-sdp-uks] in the "ClientHello" message when 254 establishing a DTLS association. Likewise, the "tls-id" SDP 255 [RFC4566] attribute MUST be included in SDP sent by the endpoint in 256 both the offer and answer [RFC3264] messages as per 257 [I-D.ietf-mmusic-dtls-sdp]. 259 When receiving a "tls_id" value from the key distributor, the client 260 MUST check to ensure that value matches the "tls-id" value received 261 in SDP. If the values do not match, the endpoint MUST consider any 262 received keying material to be invalid and terminate the DTLS 263 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 "tls_id" value transmitted in the "ClientHello" 355 message and match that against "tls-id" value the endpoint 356 transmitted via SDP. If the values in SDP and the "ClientHello" do 357 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 "tls_id" received from endpoint's "ClientHello" message with the 364 corresponding values received from the SDP transmitted by the 365 endpoint. It is through this correlation that the key distributor 366 can be sure to deliver the correct conference key to the endpoint. 368 When sending the "ServerHello" message, the key distributor MUST 369 insert its own "tls_id" value in the "sdp_tls_id" extension. This 370 value MUST also be conveyed back to the client via SDP as a "tls-id" 371 attribute. 373 The key distributor MUST encapsulate any DTLS message it sends to an 374 endpoint inside a "TunneledDtls" message (see Section 6). The key 375 distributor is not required to transmit all messages a given DTLS 376 association through the same tunnel if more than one tunnel has been 377 established between it and a media distributor. 379 The key distributor MUST use the same association identifier in 380 messages sent to an endpoint as was received in messages from that 381 endpoint. This ensures the media distributor can forward the 382 messages to the correct endpoint. 384 The key distributor extracts tunneled DTLS messages from an endpoint 385 and acts on those messages as if that endpoint had established the 386 DTLS association directly with the key distributor. The key 387 distributor is acting as the DTLS server and the endpoint is acting 388 as the DTLS client. The handling of the messages and certificates is 389 exactly the same as normal DTLS-SRTP procedures between endpoints. 391 The key distributor MUST send a "MediaKeys" message to the media 392 distributor as soon as the HBH encryption key is computed and before 393 it sends a DTLS "Finished" message to the endpoint. The "MediaKeys" 394 message includes the selected cipher (i.e. protection profile), MKI 395 [RFC3711] value (if any), SRTP master keys, and SRTP master salt 396 values. The key distributor MUST use the same association identifier 397 in the "MediaKeys" message as is used in the "TunneledDtls" messages 398 for the given endpoint. 400 The key distributor uses the certificate fingerprint of the endpoint 401 along with the "tls_id" value received in the "sdp_tls_id" extension 402 to determine which conference a given DTLS association is associated. 404 The key distributor MUST select a cipher that is supported by both 405 the endpoint and the media distributor to ensure proper HBH 406 operations. 408 When the DTLS association between the endpoint and the key 409 distributor is terminated, regardless of which entity initiated the 410 termination, the key distributor MUST send an "EndpointDisconnect" 411 message with the association identifier assigned to the endpoint to 412 the media distributor. 414 5.5. Versioning Considerations 416 All messages for an established tunnel MUST utilize the same version 417 value. 419 Since the media distributor sends the first message over the tunnel, 420 it effectively establishes the version of the protocol to be used. 422 If that version is not supported by the key distributor, it MUST 423 discard the message, transmit an "UnsupportedVersion" message, and 424 close the TLS connection. 426 The media distributor MUST take note of the version received in an 427 "UnsupportedVersion" message and use that version when attempting to 428 re-establish a failed tunnel connection. Note that it is not 429 necessary for the media distributor to understand the newer version 430 of the protocol to understand that the first message received is 431 "UnsupportedVersion". The media distributor can determine from the 432 first two octets received what the version number is and that the 433 message is "UnsupportedVersion". The rest of the data received, if 434 any, would be discarded and the connection closed (if not already 435 closed). 437 6. Tunneling Protocol 439 Tunneled messages are transported via the TLS tunnel as application 440 data between the media distributor and the key distributor. Tunnel 441 messages are specified using the format described in [RFC5246] 442 section 4. As in [RFC5246], all values are stored in network byte 443 (big endian) order; the uint32 represented by the hex bytes 01 02 03 444 04 is equivalent to the decimal value 16909060. 446 The protocol defines several different messages, each of which 447 containing the the following information: 449 o Protocol version 451 o Message type identifier 453 o The message body 455 Each of these messages is a "TunnelMessage" in the syntax, with a 456 message type indicating the actual content of the message body. 458 6.1. Tunnel Message Format 460 The syntax of the protocol is defined below. "TunnelMessage" defines 461 the structure of all messages sent via the tunnel protocol. That 462 structure includes a field called "msg_type" that identifies the 463 specific type of message contained within "TunnelMessage". 465 enum { 466 supported_profiles(1), 467 unsupported_version(2), 468 media_keys(3), 469 tunneled_dtls(4), 470 endpoint_disconnect(5), 471 (255) 472 } MsgType; 474 opaque uuid[16]; 476 struct { 477 MsgType msg_type; 478 uint16 length; 479 select (MsgType) { 480 case supported_profiles: SupportedProfiles; 481 case unsupported_version: UnsupportedVersion; 482 case media_keys: MediaKeys; 483 case tunneled_dtls: TunneledDtls; 484 case endpoint_disconnect: EndpointDisconnect; 485 } body; 486 } TunnelMessage; 488 The elements of "TunnelMessage" include: 490 o msg_type: the type of message contained within the structure 491 "body". 493 o length: the length in octets of the following "body" of the 494 message. 496 The "SupportedProfiles" message is defined as: 498 uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ 500 struct { 501 uint8 version; 502 SRTPProtectionProfile protection_profiles<0..2^16-1>; 503 } SupportedProfiles; 505 This message contains this single element: 507 o version: indicates the version of this protocol (0x00). 509 o protection_profiles: The list of two-octet SRTP protection profile 510 values as per [RFC5764] supported by the media distributor. 512 The "UnsupportedVersion" message is defined as follows: 514 struct { 515 uint8 highest_version; 516 } UnsupportedVersion; 518 The elements of "UnsupportedVersion" include: 520 o highest_version: indicates the highest supported protocol version. 522 The "MediaKeys" message is defined as: 524 struct { 525 uuid association_id; 526 SRTPProtectionProfile protection_profile; 527 opaque mki<0..255>; 528 opaque client_write_SRTP_master_key<1..255>; 529 opaque server_write_SRTP_master_key<1..255>; 530 opaque client_write_SRTP_master_salt<1..255>; 531 opaque server_write_SRTP_master_salt<1..255>; 532 } MediaKeys; 534 The fields are described as follows: 536 o association_id: A value that identifies a distinct DTLS 537 association between an endpoint and the key distributor. 539 o protection_profiles: The value of the two-octet SRTP protection 540 profile value as per [RFC5764] used for this DTLS association. 542 o mki: Master key identifier [RFC3711]. 544 o client_write_SRTP_master_key: The value of the SRTP master key 545 used by the client (endpoint). 547 o server_write_SRTP_master_key: The value of the SRTP master key 548 used by the server (media distributor). 550 o client_write_SRTP_master_salt: The value of the SRTP master salt 551 used by the client (endpoint). 553 o server_write_SRTP_master_salt: The value of the SRTP master salt 554 used by the server (media distributor). 556 The "TunneledDtls" message is defined as: 558 struct { 559 uuid association_id; 560 opaque dtls_message<0..2^16-1>; 561 } TunneledDtls; 562 The fields are described as follows: 564 o association_id: An value that identifies a distinct DTLS 565 association between an endpoint and the key distributor. 567 o dtls_message: the content of the DTLS message received by the 568 endpoint or to be sent to the endpoint. 570 The "EndpointDisconect" message is defined as: 572 struct { 573 uuid association_id; 574 } EndpointDisconnect; 576 The fields are described as follows: 578 o association_id: An value that identifies a distinct DTLS 579 association between an endpoint and the key distributor. 581 7. Example Binary Encoding 583 The "TunnelMessage" is encoded in binary following the procedures 584 specified in [RFC5246]. This section provides an example of what the 585 bits on the wire would look like for the "SupportedProfiles" message 586 that advertises support for both 587 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 588 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [I-D.ietf-perc-double]. 590 RFC Editor Note: Please replace the values 0009 and 000A in the 591 following two examples with whatever code points IANA assigned for 592 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 593 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. 595 TunnelMessage: 596 message_type: 0x01 597 length: 0x0007 598 SupportedProfiles: 599 version: 0x00 600 protection_profiles: 0x0004 (length) 601 0x0009000A (value) 603 Thus, the encoding on the wire presented here in network bytes order 604 would be this stream of octets: 606 0x0100070000040009000A 608 8. IANA Considerations 610 This document establishes a new registry to contain message type 611 values used in the DTLS Tunnel protocol. These data type values are 612 a single octet in length. This document defines the values shown in 613 Table 1 below, leaving the balance of possible values reserved for 614 future specifications: 616 +---------+------------------------------------+ 617 | MsgType | Description | 618 +---------+------------------------------------+ 619 | 0x01 | Supported SRTP Protection Profiles | 620 | 0x02 | Unsupported Version | 621 | 0x03 | Media Keys | 622 | 0x04 | Tunneled DTLS | 623 | 0x05 | Endpoint Disconnect | 624 +---------+------------------------------------+ 626 Table 1: Data Type Values for the DTLS Tunnel Protocol 628 The value 0x00 and all values in the range 0x06 to 0xFF are reserved. 630 The name for this registry is "Datagram Transport Layer Security 631 (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing". 633 9. Security Considerations 635 The encapsulated data is protected by the TLS connection from the 636 endpoint to key distributor, and the media distributor is merely an 637 on path entity. The media distributor does not have access to the 638 end-to-end keying material This does not introduce any additional 639 security concerns beyond a normal DTLS-SRTP association. 641 The HBH keying material is protected by the mutual authenticated TLS 642 connection between the media distributor and key distributor. The 643 key distributor MUST ensure that it only forms associations with 644 authorized media distributors or it could hand HBH keying material to 645 untrusted parties. 647 The supported profiles information sent from the media distributor to 648 the key distributor is not particularly sensitive as it only provides 649 the cryptographic algorithms supported by the media distributor. 650 Further, it is still protected by the TLS connection between the 651 media distributor and the key distributor. 653 10. Acknowledgments 655 The author would like to thank David Benham and Cullen Jennings for 656 reviewing this document and providing constructive comments. 658 11. References 660 11.1. Normative References 662 [I-D.ietf-mmusic-dtls-sdp] 663 Holmberg, C. and R. Shpount, "Session Description Protocol 664 (SDP) Offer/Answer Considerations for Datagram Transport 665 Layer Security (DTLS) and Transport Layer Security (TLS)", 666 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 667 2017. 669 [I-D.thomson-mmusic-sdp-uks] 670 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 671 uses of Transport Layer Security with the Session 672 Description Protocol (SDP)", draft-thomson-mmusic-sdp- 673 uks-00 (work in progress), April 2017. 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, 677 DOI 10.17487/RFC2119, March 1997, 678 . 680 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 681 with Session Description Protocol (SDP)", RFC 3264, 682 DOI 10.17487/RFC3264, June 2002, 683 . 685 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 686 Jacobson, "RTP: A Transport Protocol for Real-Time 687 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 688 July 2003, . 690 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 691 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 692 RFC 3711, DOI 10.17487/RFC3711, March 2004, 693 . 695 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 696 Unique IDentifier (UUID) URN Namespace", RFC 4122, 697 DOI 10.17487/RFC4122, July 2005, 698 . 700 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 701 (TLS) Protocol Version 1.2", RFC 5246, 702 DOI 10.17487/RFC5246, August 2008, 703 . 705 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 706 Security (DTLS) Extension to Establish Keys for the Secure 707 Real-time Transport Protocol (SRTP)", RFC 5764, 708 DOI 10.17487/RFC5764, May 2010, 709 . 711 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 712 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 713 January 2012, . 715 11.2. Informative References 717 [I-D.ietf-perc-double] 718 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 719 Double Encryption Procedures", draft-ietf-perc-double-10 720 (work in progress), October 2018. 722 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 723 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 724 July 2006, . 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