idnits 2.17.1 draft-ietf-perc-dtls-tunnel-02.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 (October 30, 2017) is 2368 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 472 -- Looks like a reference, but probably isn't: '2' on line 495 ** 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-07 -- 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: May 3, 2018 Princeton University 6 N. Ohlmeier 7 Mozilla 8 October 30, 2017 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-ietf-perc-dtls-tunnel-02 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 http://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 May 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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) 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 450 o Message type identifier 451 o The message body 453 Each of these messages is a "TunnelMessage" in the syntax, with a 454 message type indicating the actual content of the message body. 456 6.1. Tunnel Message Format 458 The syntax of the protocol is defined below. "TunnelMessage" defines 459 the structure of all messages sent via the tunnel protocol. That 460 structure includes a field called "msg_type" that identifies the 461 specific type of message contained within "TunnelMessage". 463 enum { 464 supported_profiles(1), 465 unsupported_version(2), 466 media_keys(3), 467 tunneled_dtls(4), 468 endpoint_disconnect(5), 469 (255) 470 } MsgType; 472 opaque uuid[16]; 474 struct { 475 MsgType msg_type; 476 uint16 length; 477 select (MsgType) { 478 case supported_profiles: SupportedProfiles; 479 case unsupported_version: UnsupportedVersion; 480 case media_keys: MediaKeys; 481 case tunneled_dtls: TunneledDtls; 482 case endpoint_disconnect: EndpointDisconnect; 483 } body; 484 } TunnelMessage; 486 The elements of "TunnelMessage" include: 488 o msg_type: the type of message contained within the structure 489 "body". 490 o length: the length in octets of the following "body" of the 491 message. 493 The "SupportedProfiles" message is defined as: 495 uint8 SRTPProtectionProfile[2]; /* from RFC5764 */ 497 struct { 498 uint8 version; 499 SRTPProtectionProfile protection_profiles<0..2^16-1>; 500 } SupportedProfiles; 502 This message contains this single element: 504 o version: indicates the version of this protocol (0x00). 505 o protection_profiles: The list of two-octet SRTP protection profile 506 values as per [RFC5764] supported by the media distributor. 508 The "UnsupportedVersion" message is defined as follows: 510 struct { 511 uint8 highest_version; 512 } UnsupportedVersion; 514 The elements of "UnsupportedVersion" include: 516 o highest_version: indicates the highest supported protocol version. 518 The "MediaKeys" message is defined as: 520 struct { 521 uuid association_id; 522 SRTPProtectionProfile protection_profile; 523 opaque mki<0..255>; 524 opaque client_write_SRTP_master_key<1..255>; 525 opaque server_write_SRTP_master_key<1..255>; 526 opaque client_write_SRTP_master_salt<1..255>; 527 opaque server_write_SRTP_master_salt<1..255>; 528 } MediaKeys; 530 The fields are described as follows: 532 o association_id: A value that identifies a distinct DTLS 533 association between an endpoint and the key distributor. 534 o protection_profiles: The value of the two-octet SRTP protection 535 profile value as per [RFC5764] used for this DTLS association. 536 o mki: Master key identifier [RFC3711]. 537 o client_write_SRTP_master_key: The value of the SRTP master key 538 used by the client (endpoint). 539 o server_write_SRTP_master_key: The value of the SRTP master key 540 used by the server (media distributor). 541 o client_write_SRTP_master_salt: The value of the SRTP master salt 542 used by the client (endpoint). 543 o server_write_SRTP_master_salt: The value of the SRTP master salt 544 used by the server (media distributor). 546 The "TunneledDtls" message is defined as: 548 struct { 549 uuid association_id; 550 opaque dtls_message<0..2^16-1>; 551 } TunneledDtls; 553 The fields are described as follows: 555 o association_id: An value that identifies a distinct DTLS 556 association between an endpoint and the key distributor. 558 o dtls_message: the content of the DTLS message received by the 559 endpoint or to be sent to the endpoint. 561 The "EndpointDisconect" message is defined as: 563 struct { 564 uuid association_id; 565 } EndpointDisconnect; 567 The fields are described as follows: 569 o association_id: An value that identifies a distinct DTLS 570 association between an endpoint and the key distributor. 572 7. Example Binary Encoding 574 The "TunnelMessage" is encoded in binary following the procedures 575 specified in [RFC5246]. This section provides an example of what the 576 bits on the wire would look like for the "SupportedProfiles" message 577 that advertises support for both 578 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 579 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM [I-D.ietf-perc-double]. 581 RFC Editor Note: Please replace the values 0009 and 000A in the 582 following two examples with whatever code points IANA assigned for 583 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 584 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. 586 TunnelMessage: 587 message_type: 0x01 588 length: 0x0007 589 SupportedProfiles: 590 version: 0x00 591 protection_profiles: 0x0004 (length) 592 0x0009000A (value) 594 Thus, the encoding on the wire presented here in network bytes order 595 would be this stream of octets: 597 0x0100070000040009000A 599 8. IANA Considerations 601 This document establishes a new registry to contain message type 602 values used in the DTLS Tunnel protocol. These data type values are 603 a single octet in length. This document defines the values shown in 604 Table 1 below, leaving the balance of possible values reserved for 605 future specifications: 607 +---------+------------------------------------+ 608 | MsgType | Description | 609 +---------+------------------------------------+ 610 | 0x01 | Supported SRTP Protection Profiles | 611 | 0x02 | Unsupported Version | 612 | 0x03 | Media Keys | 613 | 0x04 | Tunneled DTLS | 614 | 0x05 | Endpoint Disconnect | 615 +---------+------------------------------------+ 617 Table 1: Data Type Values for the DTLS Tunnel Protocol 619 The value 0x00 and all values in the range 0x06 to 0xFF are reserved. 621 The name for this registry is "Datagram Transport Layer Security 622 (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing". 624 9. Security Considerations 626 The encapsulated data is protected by the TLS connection from the 627 endpoint to key distributor, and the media distributor is merely an 628 on path entity. The media distributor does not have access to the 629 end-to-end keying material This does not introduce any additional 630 security concerns beyond a normal DTLS-SRTP association. 632 The HBH keying material is protected by the mutual authenticated TLS 633 connection between the media distributor and key distributor. The 634 key distributor MUST ensure that it only forms associations with 635 authorized media distributors or it could hand HBH keying material to 636 untrusted parties. 638 The supported profiles information sent from the media distributor to 639 the key distributor is not particularly sensitive as it only provides 640 the cryptographic algorithms supported by the media distributor. 641 Further, it is still protected by the TLS connection between the 642 media distributor and the key distributor. 644 10. Acknowledgments 646 The author would like to thank David Benham and Cullen Jennings for 647 reviewing this document and providing constructive comments. 649 11. References 650 11.1. Normative References 652 [I-D.ietf-mmusic-dtls-sdp] 653 Holmberg, C. and R. Shpount, "Session Description Protocol 654 (SDP) Offer/Answer Considerations for Datagram Transport 655 Layer Security (DTLS) and Transport Layer Security (TLS)", 656 draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 657 2017. 659 [I-D.thomson-mmusic-sdp-uks] 660 Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on 661 uses of Transport Layer Security with the Session 662 Description Protocol (SDP)", draft-thomson-mmusic-sdp- 663 uks-00 (work in progress), April 2017. 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, 667 DOI 10.17487/RFC2119, March 1997, . 670 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 671 with Session Description Protocol (SDP)", RFC 3264, 672 DOI 10.17487/RFC3264, June 2002, . 675 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 676 Jacobson, "RTP: A Transport Protocol for Real-Time 677 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 678 July 2003, . 680 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 681 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 682 RFC 3711, DOI 10.17487/RFC3711, March 2004, 683 . 685 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 686 Unique IDentifier (UUID) URN Namespace", RFC 4122, 687 DOI 10.17487/RFC4122, July 2005, . 690 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 691 (TLS) Protocol Version 1.2", RFC 5246, 692 DOI 10.17487/RFC5246, August 2008, . 695 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 696 Security (DTLS) Extension to Establish Keys for the Secure 697 Real-time Transport Protocol (SRTP)", RFC 5764, 698 DOI 10.17487/RFC5764, May 2010, . 701 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 702 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 703 January 2012, . 705 11.2. Informative References 707 [I-D.ietf-perc-double] 708 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 709 Double Encryption Procedures", draft-ietf-perc-double-07 710 (work in progress), September 2017. 712 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 713 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 714 July 2006, . 716 Authors' Addresses 718 Paul E. Jones 719 Cisco Systems, Inc. 720 7025 Kit Creek Rd. 721 Research Triangle Park, North Carolina 27709 722 USA 724 Phone: +1 919 476 2048 725 Email: paulej@packetizer.com 727 Paul M. Ellenbogen 728 Princeton University 730 Phone: +1 206 851 2069 731 Email: pe5@cs.princeton.edu 733 Nils H. Ohlmeier 734 Mozilla 736 Phone: +1 408 659 6457 737 Email: nils@ohlmeier.org