idnits 2.17.1 draft-jones-perc-dtls-tunnel-03.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 (July 8, 2016) is 2849 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) ** 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 (==), 2 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 July 8, 2016 5 Expires: January 9, 2017 7 A DTLS Tunnel between Media Distributor and Key Distributor to 8 Facilitate Key Exchange 9 draft-jones-perc-dtls-tunnel-03 11 Abstract 13 This document defines a DTLS tunneling protocol for use in multimedia 14 conferences that enables a Media Distributor to facilitate key 15 exchange between an endpoint in a conference and the Key Distributor. 16 The protocol is designed to ensure that the keying material used for 17 hop-by-hop encryption and authentication is accessible to the media 18 distributor, while the keying material used for end-to-end encryption 19 and authentication is inaccessible to the media distributor. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 9, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 57 3. Tunneling Concept . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Example Message Flows . . . . . . . . . . . . . . . . . . . . 4 59 5. Tunneling Procedures . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Endpoint Procedures . . . . . . . . . . . . . . . . . . . 6 61 5.2. Tunnel Establishment Procedures . . . . . . . . . . . . . 6 62 5.3. Media Distributor Tunneling Procedures . . . . . . . . . 6 63 5.4. Key Distributor Tunneling Procedures . . . . . . . . . . 8 64 6. Tunneling Protocol . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Tunnel Message . . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Tunnel Message + Profiles . . . . . . . . . . . . . . . . 9 67 6.3. Tunnel Message + Key Info . . . . . . . . . . . . . . . . 10 68 7. PMTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8. To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 73 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 An objective of the work in the Privacy-Enhanced RTP Conferencing 79 (PERC) working group is to ensure that endpoints in a multimedia 80 conference have access to the end-to-end (E2E) and hop-by-hop (HBH) 81 keying material used to encrypt and authenticate Real-time Transport 82 Protocol (RTP) [RFC3550] packets, while the Media Distributor has 83 access only to the hop-by-hop (HBH) keying material for encryption 84 and authentication. 86 This specification defines a tunneling protocol that enables the 87 media distributor to tunnel DTLS [RFC6347] messages between an 88 endpoint and the key distributor, thus allowing an endpoint to use 89 DTLS-SRTP [RFC5764] for establishing encryption and authentication 90 keys with the key distributor. 92 The tunnel established between the media distributor and key 93 distributor is a DTLS association that is established before any 94 messages are forwarded by the media distributor on behalf of the 95 endpoint. DTLS packets received from the endpoint are encapsulated 96 by the media distributor inside this tunnel as data to be sent to the 97 key distributor. Likewise, when the media distributor receives data 98 from the key distributor over the tunnel, it extracts the DTLS 99 message inside and forwards that to the endpoint. In this way, the 100 DTLS association for the DTLS-SRTP procedures is established between 101 the endpoint and the key distributor, with the media distributor 102 simply forwarding packets between the two entities and having no 103 visibility into the confidential information exchanged. 105 Following the existing DTLS-SRTP procedures, the endpoint and key 106 distributor will arrive at a selected cipher and keying material, 107 which are used for HBH encryption and authentication by both the 108 endpoint and the media distributor. However, since the media 109 distributor would not have direct access to this information, the key 110 distributor explicitly shares the HBH key information with the media 111 distributor via the tunneling protocol defined in this document. 112 Additionally, the endpoint and key distributor will agree on a cipher 113 for E2E encryption and authentication. The key distributor will 114 transmit keying material to the endpoint for E2E operations, but will 115 not share that information with the media distributor. 117 By establishing this DTLS tunnel between the media distributor and 118 key distributor and implementing the protocol defined in this 119 document, it is possible for the media distributor to facilitate the 120 establishment of a secure DTLS association between an endpoint and 121 the key distributor in order for the endpoint to receive E2E and HBH 122 keying material. At the same time, the key distributor can securely 123 provide the HBH keying material to the media distributor. 125 2. Conventions Used In This Document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119] when they 130 appear in ALL CAPS. These words may also appear in this document in 131 lower case as plain English words, absent their normative meanings. 133 3. Tunneling Concept 135 A DTLS association (tunnel) is established between the media 136 distributor and the key distributor. This tunnel is used to relay 137 DTLS messages between the endpoint and key distributor, as depicted 138 in Figure 1: 140 +-------------+ 141 | Key | 142 | Distributor | 143 +-------------+ 144 # ^ ^ # 145 # | | # <-- DTLS Tunnel 146 # | | # 147 +----------+ +-------------+ +----------+ 148 | | DTLS | | DTLS | | 149 | Endpoint |<------------| Media |------------>| Endpoint | 150 | | to Key | Distributor | to Key | | 151 | | Distributor | | Distributor | | 152 +----------+ +-------------+ +----------+ 154 Figure 1: DTLS Tunnel to Key Distributor 156 The three entities involved in this communication flow are the 157 endpoint, the media distributor, and the key distributor. The 158 behavior of each entity is described in Section 5. 160 The key distributor is a logical function that might might be co- 161 resident with a key management server operated by an enterprise, 162 reside in one of the endpoints participating in the conference, or 163 elsewhere that is trusted with E2E keying material. This document 164 does not preclude any location, only requiring that the key 165 distributor not allow the media distributor to gain access to the E2E 166 keying material by following the procedures defined in this document. 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 DTLS association for the purpose of sending tunneled 174 messages, though the complete DTLS 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. The message used to tunnel the DTLS messages is 186 named "Tunnel" and can include Profiles or Key Info data. 188 Endpoint media distributor key distributor 189 | | | 190 | |<========================| 191 | | DTLS Association Made | 192 | | | 193 |------------------------>|========================>| 194 | DTLS handshake message | Tunnel + Profiles | 195 | | | 196 |<------------------------|<========================| 197 | DTLS handshake message | Tunnel | 198 | | | 199 .... may be multiple handshake messages ... 200 |------------------------>|========================>| 201 | DTLS handshake message | Tunnel + Profiles | 202 | | | 203 |<------------------------|<========================| 204 | DTLS handshake message | Tunnel + Key Info | 205 | (including Finished) | | 206 | | | 208 Figure 2: Sample DTLS-SRTP Exchange via the Tunnel 210 Each of these tunneled messages on the right-hand side of Figure 2 is 211 a message of type "Tunnel" (see Section 6). Each message contains 212 the following information: 214 o Protocol version 215 o Association ID 216 o DTLS message being tunneled 218 All messages sent by the media distributor will contain SRTP 219 protection profiles supported by the media distributor at the end of 220 the Tunnel message. The key distributor will select a common profile 221 supported by both the endpoint and the media distributor to ensure 222 that hop-by-hop operations can be successfully performed. 224 Further, the key distributor will provide the SRTP [RFC3711] keying 225 material to the media distributor for HBH operations at the time it 226 sends a DTLS Finished message to the endpoint via the tunnel. The 227 media distributor would extract this Key Info when received and use 228 it for hop-by-hop encryption and authentication. The delivery of the 229 keying information along with the completion of the DTLS handshake 230 ensures the delivery of the keying information is fate shared with 231 completion of the DTLS handshake. This guarantees that the media 232 distributor will have the HBH keying information before it receives 233 any media that is encrypted or authenticated with that key. 235 5. Tunneling Procedures 237 The following sub-sections explain in detail the expected behavior of 238 the endpoint, the media distributor, and the key distributor. 240 It is important to note that the tunneling protocol described in this 241 document is not an extension to TLS [RFC5246] or DTLS [RFC6347]. 242 Rather, it is a protocol that transports DTLS messages generated by 243 an endpoint or key distributor as data inside of the DTLS association 244 established between the media distributor and key distributor. 246 5.1. Endpoint Procedures 248 The endpoint follows the procedures outlined for DTLS-SRTP [RFC5764] 249 in order to establish the cipher and keys used for encryption and 250 authentication, with the endpoint acting as the client and the key 251 distributor acting as the server. The endpoint does not need to be 252 aware of the fact that DTLS messages it transmits toward the media 253 distributor are being tunneled to the key distributor. 255 5.2. Tunnel Establishment Procedures 257 Either the media distributor or key distributor initiates the 258 establishment of a DTLS tunnel. Which entity acts as the DTLS client 259 when establishing the tunnel and what event triggers the 260 establishment of the tunnel are outside the scope of this document. 261 Further, how the trust relationships are established between the key 262 distributor and media distributor are also outside the scope of this 263 document. 265 A tunnel MUST be a mutually authenticated DTLS association. It is 266 used to relay DTLS messages between any number of endpoints and the 267 key distributor. 269 The media distributor or key distributor MUST establish a tunnel in 270 advance of, or no later than the point, when an endpoint attempts to 271 establish a DTLS association with 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. Media Distributor Tunneling Procedures 280 The media distributor MUST forward all messages received from an 281 endpoint for a given DTLS association through the same tunnel if more 282 than one tunnel has been established between it and a key 283 distributor. A media distributor is not precluded from establishing 284 more than one tunnel to a given key distributor. 286 Editor's Note: Do we want to have the above requirement or would 287 we prefer to allow the media distributor to send messages over 288 more than one tunnel to more than one key distributor? The latter 289 would provide for higher availability, but at the cost of key 290 distributor complexity. 292 The media distributor MUST assign a unique "association identifier" 293 for each endpoint-initiated DTLS association and include it in all 294 messages forwarded to the key distributor. The key distributor will 295 subsequently include in this identifier in all messages it sends so 296 that the media distributor can map messages received via a tunnel and 297 forward those messages to the correct endpoint. The association 298 identifier SHOULD be randomly assigned and values not re-used for a 299 period of time sufficient to ensure no late-arriving messages might 300 be delivered to the wrong endpoint. It is RECOMMENDED that the 301 association identifier not be re-used for at least 24 hours. 303 Editor's Note: do we want to recommend a time and is 24 hours 304 sufficient? 306 The tunnel protocol enables the key distributor to separately provide 307 HBH keying material to the media distributor for each of the 308 individual endpoint DTLS associations, though the media distributor 309 cannot decrypt messages between the key distributor and endpoints. 311 When a DTLS message is received by the media distributor from an 312 endpoint, it forwards the UDP payload portion of that message to the 313 key distributor encapsulated in a Tunnel + Profiles message (see 314 Section 6). The Tunnel + Profiles message allows the media 315 distributor to signal which SRTP protection profiles it supports for 316 HBH operations. 318 The media distributor MUST support the same list of protection 319 profiles for the life of a given endpoint's DTLS association, which 320 is represented by the association identifier. 322 When a message from the key distributor includes "Key Info," the 323 media distributor MUST extract the cipher and keying material 324 conveyed in order to subsequently perform HBH encryption and 325 authentication operations for RTP and RTCP packets sent between it 326 and an endpoint. Since the HBH keying material will be different for 327 each endpoint, the media distributor uses the association identifier 328 included by the key distributor to ensure that the HBH keying 329 material is used with the correct endpoint. 331 The media distributor MUST forward all messages received from either 332 the endpoint or the key distributor to ensure proper communication 333 between those two entities. 335 5.4. Key Distributor Tunneling Procedures 337 When the media distributor relays a DTLS message from an endpoint, 338 the media distributor will include an association identifier that is 339 unique per endpoint-originated DTLS association. The association 340 identifier remains constant for the life of the DTLS association. 341 The key distributor identifies each distinct endpoint-originated DTLS 342 association by the association identifier. 344 The key distributor MUST encapsulate the DTLS message inside a Tunnel 345 message (see Section 6) when sending a message to an endpoint. 347 The key distributor MUST use the same association identifier in 348 messages sent to an endpoint as was received in messages from that 349 endpoint. This ensures the media distributor can forward the 350 messages to the correct endpoint. 352 The key distributor extracts tunneled DTLS messages from an endpoint 353 and acts on those messages as if that endpoint had established the 354 DTLS association directly with the key distributor. The key 355 distributor is acting as the server and the endpoint is acting as the 356 client. The handling of the messages and certificates is exactly the 357 same as normal DTLS-SRTP procedures between endpoints. 359 The key distributor MUST send a DTLS Finished message to the endpoint 360 at the point the DTLS handshake completes using the Tunnel + Key Info 361 message. The Key Info includes the selected cipher (i.e. protection 362 profile), MKI [RFC3711] value (if any), SRTP master keys, and SRTP 363 master salt values. 365 The key distributor MUST select a cipher that is supported by both 366 the endpoint and the media distributor to ensure proper HBH 367 operations. 369 6. Tunneling Protocol 371 The tunneling protocol is transmitted over the DTLS association 372 established between the media distributor and key distributor as 373 application data. The basic message is referred to as the Tunnel 374 message. The media distributor will append supported SRTP protection 375 profiles to all Tunnel messages it sends, forming the Tunnel + 376 Profiles message. The key distributor will append information 377 necessary for the media distributor to perform HBH encryption and 378 authentication as it transmits the DTLS Finished message to the 379 endpoint, forming the Tunnel + Key Info message. The Tunnel, Tunnel 380 + Profiles, and Tunnel + Key Info messages are detailed in the 381 following sub-sections. 383 6.1. Tunnel Message 385 Tunneled DTLS messages are transported via the "Tunnel" message as 386 application data between the media distributor and the key 387 distributor. The "Tunnel" Message has the following format: 389 0 1 2 3 390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 391 +---------------------------------------------------------------+ 392 | Association Identifier | 393 +-------------------------------+-------------------------------+ 394 | DTLS Message Length | : 395 +-------------------------------+ : 396 : : 397 : Tunneled DTLS Message : 398 : : 399 +---------------------------------------------------------------+ 401 Figure 3: The "Tunnel" Message 403 Association Identifier: This is the association identifier used to 404 uniquely identify each endpoint in a conference (32-bits). 406 DTLS Message Length: Length in octets of following Tunneled DTLS 407 Message (16-bits). 409 Tunneled DTLS Message: This is the DTLS message exchanged between the 410 endpoint and key distributor. The length varies based on the value 411 specified in the previous field. 413 6.2. Tunnel Message + Profiles 415 Each Tunnel message transmitted by the media distributor contains an 416 array of SRTP protection profiles at the end of the message. The 417 format of the message is shown below: 419 0 1 2 3 420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 421 +---------------------------------------------------------------+ 422 | Association Identifier | 423 +-------------------------------+-------------------------------+ 424 | DTLS Message Length | : 425 +-------------------------------+ : 426 : : 427 : Tunneled DTLS Message : 428 : : 429 +---------------+---------------+-------------------------------+ 430 | Data Type | Length | : 431 +---------------+---------------+ : 432 : Protection Profiles : 433 +---------------------------------------------------------------+ 435 Figure 4: The "Tunnel + Profiles" Message 437 Beyond the fields included in the Tunnel message, this message 438 introduces the following additional fields. 440 Data Type: Indicates the type of data that follows. The value is 441 0x01 for SRTP protection profiles supported by the media distributor. 443 Length: This is the length in octets of the protection profiles. 444 This length must be greater than or equal to 2. 446 Protection Profiles: This is an array of two-octet SRTP protection 447 profile values as per [RFC5764], with each value represented in 448 network byte order. 450 6.3. Tunnel Message + Key Info 452 When the key distributor has HBH cipher and key information to share 453 with the media distributor, the key distributor will send a Tunnel 454 message with the Key Info appended as shown below: 456 0 1 2 3 457 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 458 +---------------------------------------------------------------+ 459 | Association Identifier | 460 +-------------------------------+-------------------------------+ 461 | DTLS Message Length | : 462 +-------------------------------+ : 463 : : 464 : Tunneled DTLS Message : 465 : : 466 +---------------+-------------------------------+---------------+ 467 | Data Type | Protection Profile | MKI Length | 468 +---------------+-------------------------------+---------------+ 469 ~ Master Key Identifier (MKI) ~ 470 +---------------+---------------+-------------------------------+ 471 | CWSMK Length | : 472 +-------------------------------+ : 473 : Client Write SRTP Master Key : 474 +-------------------------------+-------------------------------+ 475 | SWSMK Length | : 476 +-------------------------------+ : 477 : Server Write SRTP Master Key : 478 +-------------------------------+-------------------------------+ 479 | CWSMS Length | : 480 +-------------------------------+ : 481 : Client Write SRTP Master Salt : 482 +-------------------------------+-------------------------------+ 483 | SWSMS Length | : 484 +-------------------------------+ : 485 : Server Write SRTP Master Salt : 486 +---------------------------------------------------------------+ 488 Figure 5: The "Tunnel + Key Info" Message 490 Beyond the fields included in the Tunnel message, this message 491 introduces the following additional fields. 493 Data Type: Indicates the type of data that follows. This value is 494 0x02 for key information. 496 Protection Profile: This is the SRTP protection profile (see 497 [RFC5764]) the media distributor MUST use to encrypt and decrypt 498 packets sent and received between itself and the endpoint. 500 MKI Length: This is the length in octets of the MKI field. A value 501 of zero indicates that the MKI field is absent. 503 CWSMK Length: The length of the "Client Write SRTP Master Key" field. 505 Client Write SRTP Master Key: The value of the SRTP master key used 506 by the client (endpoint). 508 SWSMK Length: The length of the "Server Write SRTP Master Key" field. 510 Server Write SRTP Master Key: The value of the SRTP master key used 511 by the server (media distributor). 513 CWSMS Length: The length of the "Client Write SRTP Master Salt" 514 field. 516 Client Write SRTP Master Salt: The value of the SRTP master salt used 517 by the client (endpoint). 519 SWSMS Length: The length of the "Server Write SRTP Master Salt" 520 field. 522 Server Write SRTP Master Salt: The value of the SRTP master salt used 523 by the server (media distributor). 525 7. PMTU Considerations 527 Tunneling DTLS messages received by an endpoint inside the DTLS 528 tunnel between the media distributor and key distributor introduces 529 only a small risk of message fragmentation, particularly with the 530 initial handshake messages carrying client and server certificates. 531 The small risk of fragmentation is considered acceptable given that 532 DTLS specifies how to recover from loss of handshake messages. 534 The additional overhead required for the tunnel is calculated to be 535 approximately 50 octets for messages transmitted from the media 536 distributor to the key distributor. Messages from the key 537 distributor would generally have slightly less overhead since they do 538 not carry a list of protection profiles. The one exception is the 539 Tunnel + Key Info message, which is slightly larger as it contains 540 key and salt information for the media distributor. While the Tunnel 541 + Key Info message is larger than Tunnel + Profiles, the DTLS 542 message(s) transmitted in that flight (ChangeCipherSpec and Finished) 543 are very small and so the overhead does not impose a risk of 544 introducing packet fragmentation. 546 8. To-Do List 548 Given what is presently defined in this draft, it is not possible for 549 the key distributor to determine which conference to which a given 550 DTLS-SRTP association belongs, making it impossible for the key 551 distributor to ensure it is providing the endpoint with the correct 552 conference key. Observing the client certificate might be 553 insufficient if the same client is participating in more than one 554 conference in parallel. The media distributor and key distributor 555 may need to coordinate or exchange a "conference identifier" common 556 to the endpoints a media distributor is bridging together. 557 Alternatively, information the key distributor needs to know about 558 conference-to-endpoint correlations might be satisfied by getting 559 info directly from the endpoints, or some trusted entity on their 560 behalf, via some other means. Need to revisit this design choice in 561 the context of all the alternatives. 563 9. IANA Considerations 565 This document establishes a new registry to contain "data type" 566 values used in the DTLS Tunnel protocol. These data type values are 567 a single octet in length. This document defines the values shown in 568 Table 1 below, leaving the balance of possible values reserved for 569 future specifications: 571 +-----------+------------------------------------+ 572 | Data Type | Description | 573 +-----------+------------------------------------+ 574 | 0x01 | Supported SRTP Protection Profiles | 575 | 0x02 | Key Information | 576 +-----------+------------------------------------+ 578 Table 1: Data Type Values for the DTLS Tunnel Protocol 580 The name for this registry is "Datagram Transport Layer Security 581 (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing." 583 10. Security Considerations 585 TODO - Much more needed. 587 The encapsulated data is protected by the DTLS session from the 588 endpoint to key distributor and the media distributor is merely an on 589 path entity. This does not introduce any additional security 590 concerns beyond a normal DTLS-SRTP session. 592 The HBH keying material is protected by the mutual authenticated DTLS 593 session between the media distributor and key distributor. The key 594 distributor MUST ensure that it only forms associations with 595 authorized media distributors or it could hand HBH keying information 596 to untrusted parties. 598 The supported profile information send from the media distributor to 599 the key distributor is not particularly sensitive as it only provides 600 the crypt algorithms supported by the media distributor but it is 601 still protected by the DTLS session from the media distributor to key 602 distributor. 604 11. Acknowledgments 606 The author would like to thank David Benham and Cullen Jennings for 607 reviewing this document and providing constructive comments. 609 12. Normative References 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 613 RFC2119, March 1997, 614 . 616 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 617 Jacobson, "RTP: A Transport Protocol for Real-Time 618 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 619 July 2003, . 621 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 622 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 623 RFC 3711, DOI 10.17487/RFC3711, March 2004, 624 . 626 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 627 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 628 RFC5246, August 2008, 629 . 631 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 632 Security (DTLS) Extension to Establish Keys for the Secure 633 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 634 10.17487/RFC5764, May 2010, 635 . 637 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 638 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 639 January 2012, . 641 Author's Address 642 Paul Jones 643 Cisco Systems 644 7025 Kit Creek Rd. 645 Research Triangle Park, North Carolina 27709 646 USA 648 Phone: +1 919 476 2048 649 Email: paulej@packetizer.com