idnits 2.17.1 draft-jones-perc-dtls-tunnel-04.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 31, 2016) is 2734 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: '2' on line 481 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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 4, 2017 Princeton University 6 N. Ohlmeier 7 Mozilla 8 October 31, 2016 10 DTLS Tunnel between a Media Distributor and Key Distributor to 11 Facilitate Key Exchange 12 draft-jones-perc-dtls-tunnel-04 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 4, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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. Versioning Considerations . . . . . . . . . . . . . . . . 7 66 5.4. Media Distributor Tunneling Procedures . . . . . . . . . 7 67 5.5. Key Distributor Tunneling Procedures . . . . . . . . . . 9 68 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Tunnel Message Format . . . . . . . . . . . . . . . . . . 10 70 7. Example Binary Encoding . . . . . . . . . . . . . . . . . . . 12 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 11.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 An objective of the work in the Privacy-Enhanced RTP Conferencing 82 (PERC) working group is to ensure that endpoints in a multimedia 83 conference have access to the end-to-end (E2E) and hop-by-hop (HBH) 84 keying material used to encrypt and authenticate Real-time Transport 85 Protocol (RTP) [RFC3550] packets, while the Media Distributor has 86 access only to the hop-by-hop (HBH) keying material for encryption 87 and authentication. 89 This specification defines a tunneling protocol that enables the 90 media distributor to tunnel DTLS [RFC6347] messages between an 91 endpoint and the key distributor, thus allowing an endpoint to use 92 DTLS-SRTP [RFC5764] for establishing encryption and authentication 93 keys with the key distributor. 95 The tunnel established between the media distributor and key 96 distributor is a TLS connection that is established before any 97 messages are forwarded by the media distributor on behalf of the 98 endpoint. DTLS packets received from the endpoint are encapsulated 99 by the media distributor inside this tunnel as data to be sent to the 100 key distributor. Likewise, when the media distributor receives data 101 from the key distributor over the tunnel, it extracts the DTLS 102 message inside and forwards the DTLS message to the endpoint. In 103 this way, the DTLS association for the DTLS-SRTP procedures is 104 established between the endpoint and the key distributor, with the 105 media distributor simply forwarding packets between the two entities 106 and having no visibility into the confidential information exchanged. 108 Following the existing DTLS-SRTP procedures, the endpoint and key 109 distributor will arrive at a selected cipher and keying material, 110 which are used for HBH encryption and authentication by both the 111 endpoint and the media distributor. However, since the media 112 distributor would not have direct access to this information, the key 113 distributor explicitly shares the HBH key information with the media 114 distributor via the tunneling protocol defined in this document. 115 Additionally, the endpoint and key distributor will agree on a cipher 116 for E2E encryption and authentication. The key distributor will 117 transmit keying material to the endpoint for E2E operations, but will 118 not share that information with the media distributor. 120 By establishing this TLS tunnel between the media distributor and key 121 distributor and implementing the protocol defined in this document, 122 it is possible for the media distributor to facilitate the 123 establishment of a secure DTLS association between an endpoint and 124 the key distributor in order for the endpoint to receive E2E and HBH 125 keying material. At the same time, the key distributor can securely 126 provide the HBH keying material to the media distributor. 128 2. Conventions Used In This Document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119] when they 133 appear in ALL CAPS. These words may also appear in this document in 134 lower case as plain English words, absent their normative meanings. 136 3. Tunneling Concept 138 A TLS connection (tunnel) is established between the media 139 distributor and the key distributor. This tunnel is used to relay 140 DTLS messages between the endpoint and key distributor, as depicted 141 in Figure 1: 143 +-------------+ 144 | Key | 145 | Distributor | 146 +-------------+ 147 # ^ ^ # 148 # | | # <-- TLS Tunnel 149 # | | # 150 +----------+ +-------------+ +----------+ 151 | | DTLS | | DTLS | | 152 | Endpoint |<------------| Media |------------>| Endpoint | 153 | | to Key | Distributor | to Key | | 154 | | Distributor | | Distributor | | 155 +----------+ +-------------+ +----------+ 157 Figure 1: TLS Tunnel to Key Distributor 159 The three entities involved in this communication flow are the 160 endpoint, the media distributor, and the key distributor. The 161 behavior of each entity is described in Section 5. 163 The key distributor is a logical function that might might be co- 164 resident with a key management server operated by an enterprise, 165 reside in one of the endpoints participating in the conference, or 166 elsewhere that is trusted with E2E keying material. 168 4. Example Message Flows 170 This section provides an example message flow to help clarify the 171 procedures described later in this document. It is necessary that 172 the key distributor and media distributor establish a mutually 173 authenticated TLS connection for the purpose of sending tunneled 174 messages, though the complete TLS handshake for the tunnel is not 175 shown in Figure 2 since there is nothing new this document introduces 176 with regard to those procedures. 178 Once the tunnel is established, it is possible for the media 179 distributor to relay the DTLS messages between the endpoint and the 180 key distributor. Figure 2 shows a message flow wherein the endpoint 181 uses DTLS-SRTP to establish an association with the key distributor. 182 In the process, the media distributor shares its supported SRTP 183 protection profile information (see [RFC5764]) and the key 184 distributor shares HBH keying material and selected cipher with the 185 media distributor. 187 Endpoint media distributor key distributor 188 | | | 189 | |<=======================>| 190 | | TLS Connection Made | 191 | | | 192 | |========================>| 193 | | SupportedProfiles | 194 | | | 195 |------------------------>|========================>| 196 | DTLS handshake message | TunneledDtls | 197 | | | 198 | |<========================| 199 | | MediaKeys | 200 | | | 201 .... may be multiple handshake messages ... 202 | | | 203 |<------------------------|<========================| 204 | DTLS handshake message | TunneledDtls | 205 | | | 207 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 209 After the initial TLS connection has been established each of the 210 messages on the right-hand side of Figure 2 is a tunneling protocol 211 message as defined in Section Section 6. 213 SRTP protection profiles supported by the media distributor will be 214 sent in a "SupportedProfiles" message when the TLS tunnel is 215 initially established. The key distributor will use that information 216 to select a common profile supported by both the endpoint and the 217 media distributor to ensure that hop-by-hop operations can be 218 successfully performed. 220 As DTLS messages are received from the endpoint by the media 221 distributor, they are forwarded to the key distributor encapsulated 222 inside abbrev "TunneledDtls" message. Likewise, as "TunneledDtls" 223 messages are received by the media distributor from the key 224 distributor, the encapsulated DTLS packet is forwarded to the 225 endpoint. 227 The key distributor will provide the SRTP [RFC3711] keying material 228 to the media distributor for HBH operations via the "MediaKeys" 229 message. The media distributor will extract this keying material 230 from the "MediaKeys" message when received and use it for hop-by-hop 231 encryption and authentication. 233 5. Tunneling Procedures 235 The following sub-sections explain in detail the expected behavior of 236 the endpoint, the media distributor, and the key distributor. 238 It is important to note that the tunneling protocol described in this 239 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 240 Rather, it is a protocol that transports DTLS messages generated by 241 an endpoint or key distributor as data inside of the TLS connection 242 established between the media distributor and key distributor. 244 5.1. Endpoint Procedures 246 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 247 in order to establish the cipher and keys used for encryption and 248 authentication, with the endpoint acting as the client and the key 249 distributor acting as the server. The endpoint does not need to be 250 aware of the fact that DTLS messages it transmits toward the media 251 distributor are being tunneled to the key distributor. 253 5.2. Tunnel Establishment Procedures 255 Either the media distributor or key distributor initiates the 256 establishment of a TLS tunnel. Which entity acts as the TLS client 257 when establishing the tunnel and what event triggers the 258 establishment of the tunnel are outside the scope of this document. 259 Further, how the trust relationships are established between the key 260 distributor and media distributor are also outside the scope of this 261 document. 263 A tunnel MUST be a mutually authenticated TLS connection. 265 The media distributor or key distributor MUST establish a tunnel 266 prior to forwarding tunneled DTLS messages. Given the time-sensitive 267 nature of DTLS-SRTP procedures, a tunnel SHOULD be established prior 268 to the media distributor receiving a DTLS message from an endpoint. 270 A single tunnel MAY be used to relay DTLS messages between any number 271 of endpoints and the key distributor. 273 A media distributor MAY have more than one tunnel established between 274 itself and one or more key distributors. When multiple tunnels are 275 established, which tunnel or tunnels to use to send messages for a 276 given conference is outside the scope of this document. 278 5.3. Versioning Considerations 280 All messages for an established tunnel MUST utilize the same version 281 value. If the version of any subsequent message differs from that of 282 the initial message, that message MUST be discarded and the tunnel 283 connection closed. 285 Since the media distributor sends the first message over the tunnel, 286 it effectively establishes the version of the protocol to be used. 287 If that version is not supported by the key distributor, it MUST 288 discard the message, transmit an "UnsupportedVersion" message, and 289 close the TLS connection. 291 The media distributor MUST take note of the version received in an 292 "UnsupportedVersion" message and use that version when attempting to 293 re-establish a failed tunnel connection. Note that it is not 294 necessary for the media distributor to understand the newer version 295 of the protocol to understand that the first message received is 296 "UnsupportedVersion". The media distributor can determine from the 297 first two octets received what the version number is and that the 298 message is "UnsupportedVersion". The rest of the data received, if 299 any, would be discarded and the connection closed (if not already 300 closed). 302 5.4. Media Distributor Tunneling Procedures 304 The first message transmitted over the tunnel is the 305 "SupportedProfiles" (see Section 6). This message informs the key 306 distributor about which DTLS-SRTP profiles the media distributor 307 supports. This message MUST be sent each time a new tunnel 308 connection is established or, in the case of connection loss, when a 309 connection is re-established. 311 The media distributor MUST forward all messages received from an 312 endpoint for a given DTLS association through the same tunnel if more 313 than one tunnel has been established between it and a key 314 distributor. 316 Editor's Note: Do we want to have the above requirement or would 317 we prefer to allow the media distributor to send messages over 318 more than one tunnel to more than one key distributor? The latter 319 would provide for higher availability, but at the cost of key 320 distributor complexity. The former would allow the usage of a 321 load distributor in front of the key distributor. 323 The media distributor MUST assign a unique association identifier for 324 each endpoint-initiated DTLS association and include it in all 325 messages forwarded to the key distributor. The key distributor will 326 subsequently include this identifier in all messages it sends so that 327 the media distributor can map messages received via a tunnel and 328 forward those messages to the correct endpoint. The association 329 identifier SHOULD be randomly assigned and values not be re-used for 330 a short period of time (e.g., five minutes) to ensure any residual 331 state in the key distributor is clear and to ensure any packets 332 already transmitted from the key distributor are not directed to the 333 wrong endpoint. 335 The tunnel protocol enables the key distributor to separately provide 336 HBH keying material to the media distributor for each of the 337 individual endpoint DTLS associations, though the media distributor 338 cannot decrypt messages between the key distributor and endpoints. 340 When a DTLS message is received by the media distributor from an 341 endpoint, it forwards the UDP payload portion of that message to the 342 key distributor encapsulated in a "TuneledDtls" message. If the 343 media distributor knows which conference to which a given DTLS 344 association belongs, it can pass the conference identifier to the key 345 distributor using the "conf_id" field of the "TunneledDtls" message. 347 The media distributor MUST support the same list of protection 348 profiles for the life of a given endpoint's DTLS association, which 349 is represented by the association identifier. 351 When a "MediaKeys" message is received, the media distributor MUST 352 extract the cipher and keying material conveyed in order to 353 subsequently perform HBH encryption and authentication operations for 354 RTP and RTCP packets sent between it and an endpoint. Since the HBH 355 keying material will be different for each endpoint, the media 356 distributor uses the association identifier included by the key 357 distributor to ensure that the HBH keying material is used with the 358 correct endpoint. 360 The media distributor MUST forward all DTLS messages received from 361 either the endpoint or the key distributor (via the "TunneledDtls" 362 message) to ensure proper communication between those two entities. 364 When the media distributor detects an endpoint has disconnected or 365 when it receives conference control messages indicating the endpoint 366 is to be disconnected, the media distributors MUST send an 367 "EndpointDisconnect" message with the association identifier assigned 368 to the endpoint to the key distributor. The media distributor SHOULD 369 take a loss of all RTP and RTCP packets as an indicator that the 370 endpoint has disconnected. The particulars of how RTP and RTCP are 371 to be used to detect an endpoint disconnect, such as timeout period, 372 is not specified. The media distributor MAY use additional 373 indicators to determine when an endpoint has disconnected. 375 5.5. Key Distributor Tunneling Procedures 377 When the media distributor relays a DTLS message from an endpoint, 378 the media distributor will include an association identifier that is 379 unique per endpoint-originated DTLS association. The association 380 identifier remains constant for the life of the DTLS association. 381 The key distributor identifies each distinct endpoint-originated DTLS 382 association by the association identifier. 384 The key distributor MUST encapsulate any DTLS message it sends to an 385 endpoint inside a "TunneledDtls" message (see Section 6). 387 The key distributor MUST use the same association identifier in 388 messages sent to an endpoint as was received in messages from that 389 endpoint. This ensures the media distributor can forward the 390 messages to the correct endpoint. 392 The key distributor extracts tunneled DTLS messages from an endpoint 393 and acts on those messages as if that endpoint had established the 394 DTLS association directly with the key distributor. The key 395 distributor is acting as the DTLS server and the endpoint is acting 396 as the DTLS client. The handling of the messages and certificates is 397 exactly the same as normal DTLS-SRTP procedures between endpoints. 399 The key distributor MUST send a "MediaKeys" message to the media 400 distributor as soon as the HBH encryption key is computed and before 401 it sends a DTLS "Finished" message to the endpoint. The "MediaKeys" 402 message includes the selected cipher (i.e. protection profile), MKI 403 [RFC3711] value (if any), SRTP master keys, and SRTP master salt 404 values. The key distributor MUST use the same association identifier 405 in the "MediaKeys" message as is used in the "TunneledDtls" messages 406 for the given endpoint. 408 The key distributor, can use the certificate of the endpoint and 409 correlate that with signaling information to know which conference 410 this session is associated with. The key distributor informs the 411 media distributor of which conference this session is associated by 412 sending a globally unique conference identifier in the "conf_id" 413 attribute of the "MediaKeys". 415 The key distributor MUST select a cipher that is supported by both 416 the endpoint and the media distributor to ensure proper HBH 417 operations. 419 6. Tunneling Protocol 421 Tunneled messages are transported via the TLS tunnel as application 422 data between the media distributor and the key distributor. Tunnel 423 messages are specified using the format described in [RFC5246] 424 section 4. As in [RFC5246], all values are stored in network byte 425 (big endian) order; the uint32 represented by the hex bytes 01 02 03 426 04 is equivalent to the decimal value 16909060. 428 The protocol defines several different messages, each of which 429 containing the the following information: 431 o Protocol version 432 o Message type identifier 433 o The message body 435 Each of these messages is a "TunnelMessage" in the syntax, with a 436 message type indicating the actual content of the message body. 438 6.1. Tunnel Message Format 440 The syntax of the protocol is defined below. "TunnelMessage" defines 441 the structure of all messages sent via the tunnel protocol. That 442 structure includes a field called "msg_type" that identifies the 443 specific type of message contained within "TunnelMessage". 445 enum { 446 unsupported_version(1), 447 supported_profiles(2), 448 media_keys(3), 449 tunneled_dtls(4), 450 endpoint_disconnect(5), 451 (255) 452 } MsgType; 454 struct { 455 uint8 version; 456 MsgType msg_type; 457 select (MsgType) { 458 case unsupported_version: UnsupportedVersion; 459 case supported_profiles: SupportedProfiles; 460 case media_keys: MediaKeys; 461 case tunneled_dtls: TunneledDtls; 462 case endpoint_disconnect: EndpointDisconnect; 463 } body; 464 } TunnelMessage; 466 The elements of "TunnelMessage" include: 468 o version: indicates the version of this protocol (0x00). 469 o msg_type: the type of message contained within the structure 470 "body". 472 The "UnsupportedVersion" message is defined as follows: 474 struct { } UnsupportedVersion; 476 The "UnsupportedVersion" message does not convey any additional 477 information in the body. 479 The "SupportedProfiles" message is defined as: 481 uint8 SRTPProtectionProfile[2]; // from RFC5764 483 struct { 484 SRTPProtectionProfile protection_profiles<0..2^16-1>; 485 } SupportedProfiles; 487 This message contains this single element: * protection_profiles: The 488 list of two-octet SRTP protection profile values as per [RFC5764] 489 supported by the media distributor. 491 The "MediaKeys" message is defined as: 493 struct { 494 uint32 association_id; 495 SRTPProtectionProfile protection_profile; 496 opaque mki<0..255>; 497 opaque client_write_SRTP_master_key<1..255>; 498 opaque server_write_SRTP_master_key<1..255>; 499 opaque client_write_SRTP_master_salt<1..255>; 500 opaque server_write_SRTP_master_salt<1..255>; 501 opaque conf_id<0..255>; 502 } MediaKeys; 504 The fields are described as follows: 506 o association_id: A value that identifies a distinct DTLS 507 association between an endpoint and the key distributor. 508 o protection_profiles: The value of the two-octet SRTP protection 509 profile value as per [RFC5764] used for this DTLS association. 510 o mki: Master key identifier [RFC3711]. 511 o client_write_SRTP_master_key: The value of the SRTP master key 512 used by the client (endpoint). 513 o server_write_SRTP_master_key: The value of the SRTP master key 514 used by the server (media distributor). 516 o client_write_SRTP_master_salt: The value of the SRTP master salt 517 used by the client (endpoint). 518 o server_write_SRTP_master_salt: The value of the SRTP master salt 519 used by the server (media distributor). 520 o conf_id: Identifier that uniquely specifies which conference the 521 media distributor should place this media flow in. 523 The "TunneledDtls" message is defined as: 525 struct { 526 uint32 association_id; 527 opaque conf_id<0..255>; 528 opaque dtls_message<0..2^16-1>; 529 } TunneledDtls; 531 The fields are described as follows: 533 o association_id: An value that identifies a distinct DTLS 534 association between an endpoint and the key distributor. 535 o conf_id: Optional identifier that uniquely specifies which 536 conference this media flow is in. 537 o dtls_message: the content of the DTLS message received by the 538 endpoint or to be sent to the endpoint. 540 The "EndpointDisconect" message is defined as: 542 struct { 543 uint32 association_id; 544 } EndpointDisconnect; 546 The fields are described as follows: 548 o association_id: An value that identifies a distinct DTLS 549 association between an endpoint and the key distributor. 551 7. Example Binary Encoding 553 The "TunnelMessage" is encoded in binary following the procedures 554 specified in [![RFC5246]]. This section provides an example of what 555 the bits on the wire would look like for the "SupportedProfiles" 556 message that advertises support for both SRTP_AEAD_AES_128_GCM and 557 SRTP_AEAD_AES_256_GCM [RFC7714]. 559 TunnelMessage: 560 version: 0x00 561 message_type: 0x01 562 SupportedProfiles: 563 protection_profiles: 0x0004 (length) 564 0x00070008 (value) 566 Thus, the encoding on the wire presented here in network bytes order 567 would be this stream of octets: 569 0x0001000400070008 571 8. IANA Considerations 573 This document establishes a new registry to contain message type 574 values used in the DTLS Tunnel protocol. These data type values are 575 a single octet in length. This document defines the values shown in 576 Table 1 below, leaving the balance of possible values reserved for 577 future specifications: 579 +---------+------------------------------------+ 580 | MsgType | Description | 581 +---------+------------------------------------+ 582 | 0x01 | Unsupported Version | 583 | 0x02 | Supported SRTP Protection Profiles | 584 | 0x03 | Media Keys | 585 | 0x04 | Tunneled DTLS | 586 | 0x05 | Endpoint Disconnect | 587 +---------+------------------------------------+ 589 Table 1: Data Type Values for the DTLS Tunnel Protocol 591 The value 0x00 and all values in the range 0x06 to 0xFF are reserved. 593 The name for this registry is "Datagram Transport Layer Security 594 (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing". 596 9. Security Considerations 598 The encapsulated data is protected by the TLS connection from the 599 endpoint to key distributor, and the media distributor is merely an 600 on path entity. The media distributor does not have access to the 601 end-to-end keying material This does not introduce any additional 602 security concerns beyond a normal DTLS-SRTP association. 604 The HBH keying material is protected by the mutual authenticated TLS 605 connection between the media distributor and key distributor. The 606 key distributor MUST ensure that it only forms associations with 607 authorized media distributors or it could hand HBH keying material to 608 untrusted parties. 610 The supported profiles information sent from the media distributor to 611 the key distributor is not particularly sensitive as it only provides 612 the cryptographic algorithms supported by the media distributor. 613 Further, it is still protected by the TLS connection between the 614 media distributor and the key distributor. 616 10. Acknowledgments 618 The author would like to thank David Benham and Cullen Jennings for 619 reviewing this document and providing constructive comments. 621 11. References 623 11.1. Normative References 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 627 RFC2119, March 1997, 628 . 630 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 631 Jacobson, "RTP: A Transport Protocol for Real-Time 632 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 633 July 2003, . 635 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 636 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 637 RFC 3711, DOI 10.17487/RFC3711, March 2004, 638 . 640 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 641 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 642 RFC5246, August 2008, 643 . 645 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 646 Security (DTLS) Extension to Establish Keys for the Secure 647 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 648 10.17487/RFC5764, May 2010, 649 . 651 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 652 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 653 January 2012, . 655 11.2. Informative References 657 [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 658 in the Secure Real-time Transport Protocol (SRTP)", RFC 659 7714, DOI 10.17487/RFC7714, December 2015, 660 . 662 Authors' Addresses 664 Paul E. Jones 665 Cisco Systems, Inc. 666 7025 Kit Creek Rd. 667 Research Triangle Park, North Carolina 27709 668 USA 670 Phone: +1 919 476 2048 671 Email: paulej@packetizer.com 673 Paul M. Ellenbogen 674 Princeton University 676 Phone: +1 206 851 2069 677 Email: pe5@cs.princeton.edu 679 Nils H. Ohlmeier 680 Mozilla 682 Phone: +1 408 659 6457 683 Email: nils@ohlmeier.org