idnits 2.17.1 draft-ietf-perc-private-media-framework-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2019) is 1855 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) == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-10 == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-09 == Outdated reference: A later version (-12) exists of draft-ietf-perc-dtls-tunnel-04 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-18 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 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 4 Intended status: Standards Track D. Benham 5 Expires: August 23, 2019 C. Groves 6 Independent 7 February 19, 2019 9 A Solution Framework for Private Media in Privacy Enhanced RTP 10 Conferencing 11 draft-ietf-perc-private-media-framework-09 13 Abstract 15 This document describes a solution framework for ensuring that media 16 confidentiality and integrity are maintained end-to-end within the 17 context of a switched conferencing environment where media 18 distributors are not trusted with the end-to-end media encryption 19 keys. The solution aims to build upon existing security mechanisms 20 defined for the real-time transport protocol (RTP). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 23, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 5 59 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 6 61 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6 62 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7 63 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7 65 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 8 67 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 9 68 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9 69 4.4. HBH Keys and Per-hop Operations . . . . . . . . . . . . . 10 70 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 11 72 4.5.2. Key Exchange during a Conference . . . . . . . . . . 12 73 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 13 75 5.2. Certificate Fingerprints in Session Signaling . . . . . . 14 76 5.3. Conferences Identification . . . . . . . . . . . . . . . 14 77 6. PERC Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. Key Inventory and Management Considerations . . . . . . . 15 79 6.2. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 15 80 6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 16 81 6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 17 82 6.5. Summary of Key Types and Entity Possession . . . . . . . 17 83 7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 18 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 19 86 8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 20 87 8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 20 88 8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 21 89 8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 21 90 8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 21 91 8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 22 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 96 11.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 100 1. Introduction 102 Switched conferencing is an increasingly popular model for multimedia 103 conferences with multiple participants using a combination of audio, 104 video, text, and other media types. With this model, real-time media 105 flows from conference participants are not mixed, transcoded, 106 transrated, recomposed, or otherwise manipulated by a Media 107 Distributor, as might be the case with a traditional media server or 108 multipoint control unit (MCU). Instead, media flows transmitted by 109 conference participants are simply forwarded by Media Distributors to 110 each of the other participants. Media Distributors often forward 111 only a subset of flows based on voice activity detection or other 112 criteria. In some instances, Media Distributors may make limited 113 modifications to RTP [RFC3550] headers, for example, but the actual 114 media content (e.g., voice or video data) is unaltered. 116 An advantage of switched conferencing is that Media Distributors can 117 be more easily deployed on general-purpose computing hardware, 118 including virtualized environments in private and public clouds. 119 Virtualized public cloud environments have been viewed as less secure 120 since resources are not always physically controlled by those who use 121 them and since there are usually several ports open to the public. 122 This document aims to improve security so as to lower the barrier to 123 taking advantage of those environments. 125 This document defines a solution framework wherein media privacy is 126 ensured by making it impossible for a media distributor to gain 127 access to keys needed to decrypt or authenticate the actual media 128 content sent between conference participants. At the same time, the 129 framework allows for the Media Distributors to modify certain RTP 130 headers; add, remove, encrypt, or decrypt RTP header extensions; and 131 encrypt and decrypt RTP Control Protocol (RTCP) [RFC3550] packets. 132 The framework also prevents replay attacks by authenticating each 133 packet transmitted between a given participant and the media 134 distributor using a unique key per endpoint that is independent from 135 the key for media encryption and authentication. 137 A goal of this document is to define a framework for enhanced privacy 138 in RTP-based conferencing environments while utilizing existing 139 security procedures defined for RTP with minimal enhancements. 141 2. Conventions Used in This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 Additionally, this solution framework uses the following terms and 150 acronyms: 152 End-to-End (E2E): Communications from one endpoint through one or 153 more Media Distributors to the endpoint at the other end. 155 Hop-by-Hop (HBH): Communications between an endpoint and a Media 156 Distributor or between Media Distributors. 158 Trusted Endpoint: An RTP flow terminating entity that has possession 159 of E2E media encryption keys and terminates E2E encryption. This may 160 include embedded user conferencing equipment or browsers on 161 computers, media gateways, MCUs, media recording device and more that 162 are in the trusted domain for a given deployment. In the context of 163 WebRTC, where control of a session is divided between a JavaScript 164 application and a browser, the browser acts as the Trusted Endpoint 165 for purposes of this framework (just as it acts as the endpoint for 166 DTLS-SRTP [RFC5764] in one-to-one calls). 168 Media Distributor (MD): An RTP middlebox that forwards endpoint media 169 content (e.g., voice or video data) unaltered, either a subset or all 170 of the flows at any given time, and is never allowed to have access 171 to E2E encryption keys. It operates according to the Selective 172 Forwarding Middlebox RTP topologies [RFC7667] per the constraints 173 defined by the PERC system, which includes, but not limited to, 174 having no access to RTP media unencrypted and having limits on what 175 RTP header field it can alter. This header fields that may be 176 modified by a Media Distributor are enumerated in Section 4 of the 177 Double cryptographic transform specification [I-D.ietf-perc-double] 178 and chosen with respect to utility and the security considerations 179 outlined in this document. 181 Key Distributor: An entity that is a logical function which 182 distributes keying material and related information to trusted 183 endpoints and Media Distributor(s), only that which is appropriate 184 for each. The Key Distributor might be co-resident with another 185 entity trusted with E2E keying material. 187 Conference: Two or more participants communicating via trusted 188 endpoints to exchange RTP flows through one or more Media 189 Distributor. 191 Call Processing: All trusted endpoints in the conference connect to 192 it by a call processing dialog, such as with the Focus defined in the 193 Framework for Conferencing with SIP [RFC4353]. 195 Third Party: Any entity that is not an Endpoint, Media Distributor, 196 Key Distributor or Call Processing entity as described in this 197 document. 199 3. PERC Entities and Trust Model 201 The following figure depicts the trust relationships, direct or 202 indirect, between entities described in the subsequent sub-sections. 203 Note that these entities may be co-located or further divided into 204 multiple, separate physical devices. 206 Please note that some entities classified as untrusted in the simple, 207 general deployment scenario used most commonly in this document might 208 be considered trusted in other deployments. This document does not 209 preclude such scenarios, but keeps the definitions and examples 210 focused by only using the the simple, most general deployment 211 scenario. 213 | 214 +----------+ | +-----------------+ 215 | Endpoint | | | Call Processing | 216 +----------+ | +-----------------+ 217 | 218 | 219 +----------------+ | +--------------------+ 220 | Key Distributor| | | Media Distributor | 221 +----------------+ | +--------------------+ 222 | 223 Trusted | Untrusted 224 Entities | Entities 225 | 227 Figure 1: Trusted and Untrusted Entities in PERC 229 3.1. Untrusted Entities 231 The architecture described in this framework document enables 232 conferencing infrastructure to be hosted in domains, such as in a 233 cloud conferencing provider's facilities, where the trustworthiness 234 is below the level needed to assume the privacy of participant's 235 media is not compromised. The conferencing infrastructure in such a 236 domain is still trusted with reliably connecting the participants 237 together in a conference, but not trusted with keying material needed 238 to decrypt any of the participant's media. Entities in such lower 239 trustworthiness domains are referred to as untrusted entities from 240 this point forward. 242 It is important to understand that untrusted in this document does 243 not mean an entity is not expected to function properly. Rather, it 244 means only that the entity does not have access to the E2E media 245 encryption keys. 247 3.1.1. Media Distributor 249 A Media Distributor forwards RTP flows between endpoints in the 250 conference while performing per-hop authentication of each RTP 251 packet. The Media Distributor may need access to one or more RTP 252 headers or header extensions, potentially adding or modifying a 253 certain subset. The Media Distributor also relays secured messaging 254 between the endpoints and the Key Distributor and acquires per-hop 255 key information from the Key Distributor. The actual media content 256 must not be decryptable by a Media Distributor, as it is untrusted to 257 have access to the E2E media encryption keys. The key exchange 258 mechanisms specified in this framework prevents the Media Distributor 259 from gaining access to the E2E media encryption keys. 261 An endpoint's ability to connect to a conference serviced by a Media 262 Distributor does imply that the endpoint is authorized to have access 263 to the E2E media encryption keys, as the Media Distributor does not 264 have the ability to determine whether an endpoint is authorized. 265 Instead, the Key Distributor is responsible for authenticating the 266 endpoint (e.g., using WebRTC Identity 267 [I-D.ietf-rtcweb-security-arch]) and determining its authorization to 268 receive E2E and HBH media encryption keys. 270 A Media Distributor must perform its role in properly forwarding 271 media packets while taking measures to mitigate the adverse effects 272 of denial of service attacks (refer to Section 8) to a level equal to 273 or better than traditional conferencing (i.e. non-PERC) deployments. 275 A Media Distributor or associated conferencing infrastructure may 276 also initiate or terminate various conference control related 277 messaging, which is outside the scope of this framework document. 279 3.1.2. Call Processing 281 The call processing function is untrusted in the simple, general 282 deployment scenario. When a physical subset of the call processing 283 function resides in facilities outside the trusted domain, it should 284 not be trusted to have access to E2E key information. 286 The call processing function may include the processing of call 287 signaling messages, as well as the signing of those messages. It may 288 also authenticate the endpoints for the purpose of call signaling and 289 subsequently joining of a conference hosted through one or more Media 290 Distributors. Call processing may optionally ensure the privacy of 291 call signaling messages between itself, the endpoint, and other 292 entities. 294 3.2. Trusted Entities 296 From the PERC model system perspective, entities considered trusted 297 (refer to Figure 1) can be in possession of the E2E media encryption 298 keys for one or more conferences. 300 3.2.1. Endpoint 302 An endpoint is considered trusted and has access to E2E key 303 information. While it is possible for an endpoint to be compromised, 304 subsequently performing in undesired ways, defining endpoint 305 resistance to compromise is outside the scope of this document. 306 Endpoints take measures to mitigate the adverse effects of denial of 307 service attacks (refer to Section 8) from other entities, including 308 from other endpoints, to a level equal to or better than traditional 309 conference (i.e., non-PERC) deployments. 311 3.2.2. Key Distributor 313 The Key Distributor, which may be colocated with an endpoint or exist 314 standalone, is responsible for providing key information to endpoints 315 for both end-to-end (E2E) and hop-by-hop (HBH) security and for 316 providing key information to Media Distributors for the hop-by-hop 317 security. 319 Interaction between the Key Distributor and the call processing 320 function is necessary for proper conference-to-endpoint mappings. 321 This is described in Section 5.3. 323 The Key Distributor needs to be secured and managed in a way to 324 prevent exploitation by an adversary, as any kind of compromise of 325 the Key Distributor puts the security of the conference at risk. 327 4. Framework for PERC 329 The purpose for this framework is to define a means through which 330 media privacy is ensured when communicating within a conferencing 331 environment consisting of one or more Media Distributors that only 332 switch, hence not terminate, media. It does not otherwise attempt to 333 hide the fact that a conference between endpoints is taking place. 335 This framework reuses several specified RTP security technologies, 336 including Secure Real-time Transport Protocol (SRTP) [RFC3711], 337 Encrypted Key Transport (EKT) [I-D.ietf-perc-srtp-ekt-diet], and 338 DTLS-SRTP [RFC5764]. 340 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 342 This solution framework focuses on the end-to-end privacy and 343 integrity of the participant's media by limiting access to only 344 trusted entities to the E2E key used for authenticated end-to-end 345 encryption. However, this framework does give a Media Distributor 346 access to RTP headers and all or most header extensions, as well as 347 the ability to modify a certain subset of those headers and to add 348 header extensions. Packets received by a Media Distributor or an 349 endpoint are authenticated hop-by-hop. 351 To enable all of the above, this framework defines the use of two 352 security contexts and two associated encryption keys: an "inner" key 353 (an E2E key distinct for each transmitted media flow) for 354 authenticated encryption of RTP media between endpoints and an 355 "outer" key (HBH key) known only to Media Distributor and the 356 adjacent endpoint) for the hop between an endpoint and a Media 357 Distributor or between Media Distributor. 359 +-------------+ +-------------+ 360 | |################################| | 361 | Media |------------------------ *----->| Media | 362 | Distributor |<----------------------*-|------| Distributor | 363 | X |#####################*#|#|######| Y | 364 | | | | | | | 365 +-------------+ | | | +-------------+ 366 # ^ | # HBH Key (XY) -+ | | # ^ | # 367 # | | # E2E Key (B) ---+ | # | | # 368 # | | # E2E Key (A) -----+ # | | # 369 # | | # # | | # 370 # | | # # | | # 371 # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # 372 # | | # # | | # 373 # *--------- E2E Key (A) E2E Key (A) ---------* # 374 # | *------- E2E Key (B) E2E Key (B) -------* | # 375 # | | # # | | # 376 # | v # # | v # 377 +-------------+ +-------------+ 378 | Endpoint A | | Endpoint B | 379 +-------------+ +-------------+ 381 Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP 382 Packets 384 The Double transform [I-D.ietf-perc-double] enables endpoints to 385 perform encryption using both the end-to-end and hop-by-hop contexts 386 while still preserving the same overall interface as other SRTP 387 transforms. The Media Distributor simply uses the corresponding 388 normal (single) AES-GCM transform, keyed with the appropriate HBH 389 keys. See Section 6.1 for a description of the keys used in PERC and 390 Section 7 for diagram of how encrypted RTP packets appear on the 391 wire. 393 RTCP is only encrypted hop-by-hop, not end-to-end. This framework 394 introduces no additional step for RTCP authenticated encryption, so 395 the procedures needed are specified in [RFC3711] and use the same 396 outer, hop-by-hop cryptographic context chosen in the Double 397 operation described above. 399 4.2. E2E Key Confidentiality 401 To ensure the confidentiality of E2E keys shared between endpoints, 402 endpoints use a common Key Encryption Key (KEK) that is known only by 403 the trusted entities in a conference. That KEK, defined in the EKT 404 [I-D.ietf-perc-srtp-ekt-diet] specification as the EKT Key, is used 405 to subsequently encrypt the SRTP master key used for E2E 406 authenticated encryption of media sent by a given endpoint. Each 407 endpoint in the conference creates an SRTP master key for E2E 408 authenticated encryption and keep track of the E2E keys received via 409 the Full EKT Tag for each distinct synchronization source (SSRC) in 410 the conference so that it can properly decrypt received media. An 411 endpoint may change its E2E key at any time and advertise that new 412 key to the conference as specified in [I-D.ietf-perc-srtp-ekt-diet]. 414 4.3. E2E Keys and Endpoint Operations 416 Any given RTP media flow is identified by its SSRC, and an endpoint 417 might send more than one at a time and change the mix of media flows 418 transmitted during the life of a conference. 420 Thus, an endpoint MUST maintain a list of SSRCs from received RTP 421 flows and each SSRC's associated E2E key information. An endpoint 422 MUST discard old E2E keys no later than when it leaves the conference 423 (see Section 4.5.2). 425 If there is a need to encrypt one or more RTP header extensions end- 426 to-end, the endpoint derives an encryption key from the E2E SRTP 427 master key to encrypt header extensions as per [RFC6904]. The Media 428 Distributor is unable use the information contained in those header 429 extensions encrypted with an E2E key. 431 4.4. HBH Keys and Per-hop Operations 433 To ensure the integrity of transmitted media packets, it is REQUIRED 434 that every packet be authenticated hop-by-hop between an endpoint and 435 a Media Distributor, as well between Media Distributors. The 436 authentication key used for hop-by-hop authentication is derived from 437 an SRTP master key shared only on the respective hop. Each HBH key 438 is distinct per hop and no two hops ever use the same SRTP master 439 key. 441 While endpoints also perform HBH authentication, the ability of the 442 endpoints to reconstruct the original RTP header also enables the 443 endpoints to authenticate RTP packets E2E. This design yields 444 flexibility to the Media Distributor to change certain RTP header 445 values as packets are forwarded. Which values the Media Distributor 446 can change in the RTP header are defined in [I-D.ietf-perc-double]. 447 RTCP can only be encrypted hop-by-hop, giving the Media Distributor 448 the flexibility to forward RTCP content unchanged, transmit compound 449 RTCP packets or to initiate RTCP packets for reporting statistics or 450 conveying other information. Performing hop-by-hop authentication 451 for all RTP and RTCP packets also helps provide replay protection 452 (see Section 8). 454 If there is a need to encrypt one or more RTP header extensions hop- 455 by-hop, the endpoint derives an encryption key from the HBH SRTP 456 master key to encrypt header extensions as per [RFC6904]. This still 457 gives the Media Distributor visibility into header extensions, such 458 as the one used to determine audio level [RFC6464] of conference 459 participants. Note that when RTP header extensions are encrypted, 460 all hops need to decrypt and re-encrypt these encrypted header 461 extensions. 463 4.5. Key Exchange 465 In brief, the keys used by any given endpoints are determined in the 466 following way: 468 o The HBH keys that the endpoint uses to send and receive SRTP media 469 are derived from a DTLS handshake that the endpoint performs with 470 the Key Distributor (following normal DTLS-SRTP procedures). 472 o The E2E key that an endpoint uses to send SRTP media can either be 473 set from DTLS or chosen by the endpoint. It is then distributed 474 to other endpoints in a Full EKT Tag, encrypted under an EKT Key 475 provided to the client by the Key Distributor within the DTLS 476 channel they negotiated. 478 o Each E2E key that an endpoint uses to receive SRTP media is set by 479 receiving a Full EKT Tag from another endpoint. 481 4.5.1. Initial Key Exchange and Key Distributor 483 The Media Distributor maintains a tunnel with the Key Distributor 484 (e.g., using [I-D.ietf-perc-dtls-tunnel]), making it possible for the 485 Media Distributor to facilitate the establishment of a secure DTLS 486 association between each endpoint and the Key Distributor as shown 487 the following figure. The DTLS association between endpoints and the 488 Key Distributor enables each endpoint to generate E2E and HBH keys 489 and receive the Key Encryption Key (KEK) (i.e., EKT Key). At the 490 same time, the Key Distributor securely provides the HBH key 491 information to the Media Distributor. The key information summarized 492 here may include the SRTP master key, SRTP master salt, and the 493 negotiated cryptographic transform. 495 +-----------+ 496 KEK info | Key | HBH Key info to 497 to Endpoints |Distributor| Endpoints & Media Distributor 498 +-----------+ 499 # ^ ^ # 500 # | | #--- Tunnel 501 # | | # 502 +-----------+ +-----------+ +-----------+ 503 | Endpoint | DTLS | Media | DTLS | Endpoint | 504 | KEK |<------------|Distributor|------------>| KEK | 505 | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | 506 +-----------+ +-----------+ +-----------+ 508 Figure 3: Exchanging Key Information Between Entities 510 In addition to the secure tunnel between the Media Distributor and 511 the Key Distributor, there are two additional types of security 512 associations utilized as a part of the key exchange as discussed in 513 the following paragraphs. One is a DTLS-SRTP association between an 514 endpoint and the Key Distributor (with packets passing through the 515 Media Distributor) and the other is a DTLS-SRTP association between 516 peer Media Distributors. 518 Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP 519 session's media ports for the purposes of key information exchange 520 with the Key Distributor. The Media Distributor does not terminate 521 the DTLS signaling, but instead forwards DTLS packets received from 522 an endpoint on to the Key Distributor (and vice versa) via a tunnel 523 established between Media Distributor and the Key Distributor. 525 In establishing the DTLS association between endpoints and the Key 526 Distributor, the endpoint MUST act as the DTLS client and the Key 527 Distributor MUST act as the DTLS server. The Key Encryption Key 528 (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the 529 DTLS association to endpoints via procedures defined in EKT 530 [I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message. 532 The Key Distributor MUST NOT establish DTLS-SRTP associations with 533 endpoints without first authenticating the Media Distributor 534 tunneling the DTLS-SRTP packets from the endpoint. 536 Note that following DTLS-SRTP procedures for the 537 [I-D.ietf-perc-double] cipher, the endpoint generates both E2E and 538 HBH encryption keys and salt values. Endpoints MUST either use the 539 DTLS-SRTP generated E2E key for transmission or generate a fresh E2E 540 key. In either case, the generated SRTP master salt for E2E 541 encryption MUST be replaced with the salt value provided by the Key 542 Distributor via the EKTKey message. That is because every endpoint 543 in the conference uses the same SRTP master salt. The endpoint only 544 transmits the SRTP master key (not the salt) used for E2E encryption 545 to other endpoints in RTP/RTCP packets per 546 [I-D.ietf-perc-srtp-ekt-diet]. 548 Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media 549 Distributor to establish the HBH key for transmitting RTP and RTCP 550 packets to that peer Media Distributor. The Key Distributor does not 551 facilitate establishing a HBH key for use between Media Distributors. 553 4.5.2. Key Exchange during a Conference 555 Following the initial key information exchange with the Key 556 Distributor, an endpoint is able to encrypt media end-to-end with an 557 E2E key, sending that E2E key to other endpoints encrypted with the 558 KEK, and is able to encrypt and authenticate RTP packets using a HBH 559 key. The procedures defined do not allow the Media Distributor to 560 gain access to the KEK information, preventing it from gaining access 561 to any endpoint's E2E key and subsequently decrypting media. 563 The KEK (i.e., EKT Key) may need to change from time-to-time during 564 the life of a conference, such as when a new participant joins or 565 leaves a conference. Dictating if, when or how often a conference is 566 to be re-keyed is outside the scope of this document, but this 567 framework does accommodate re-keying during the life of a conference. 569 When a Key Distributor decides to re-key a conference, it transmits a 570 new EKTKey message containing the new EKT Key 571 [I-D.ietf-perc-srtp-ekt-diet] to each of the conference participants. 572 Upon receipt of the new EKT Key, the endpoint MUST create a new SRTP 573 master key and prepare to send that key inside a Full EKT Field using 574 the new EKT Key as per Section 4.5 of [I-D.ietf-perc-srtp-ekt-diet]. 575 In order to allow time for all endpoints in the conference to receive 576 the new keys, the sender should follow the recommendations in 577 Section 4.7 of [I-D.ietf-perc-srtp-ekt-diet]. On receiving a new EKT 578 Key, endpoints MUST be prepared to decrypt EKT tags using the new 579 key. The EKT SPI field is used to differentiate between tags 580 encrypted with the old and new keys. 582 After re-keying, an endpoint SHOULD retain prior SRTP master keys and 583 EKT Key for a period of time sufficient for the purpose of ensuring 584 it can decrypt late-arriving or out-of-order packets or packets sent 585 by other endpoints that used the prior keys for a period of time 586 after re-keying began. An endpoint MAY retain old keys until the end 587 of the conference. 589 Endpoints MAY follow the procedures in section 5.2 of [RFC5764] to 590 renegotiate HBH keys as desired. If new HBH keys are generated, the 591 new keys are also delivered to the Media Distributor following the 592 procedures defined in [I-D.ietf-perc-dtls-tunnel] as one possible 593 method. 595 Endpoints MAY change the E2E encryption key used at any time. 596 Endpoints MUST generate a new E2E encryption key whenever it receives 597 a new EKT Key. After switching to a new key, the new key is conveyed 598 to other endpoints in the conference in RTP/RTCP packets per 599 [I-D.ietf-perc-srtp-ekt-diet]. 601 5. Authentication 603 It is important to this solution framework that the entities can 604 validate the authenticity of other entities, especially the Key 605 Distributor and endpoints. The details of this are outside the scope 606 of specification but a few possibilities are discussed in the 607 following sections. The key requirements are that an endpoint can 608 verify it is connected to the correct Key Distributor for the 609 conference and the Key Distributor can verify the endpoint is the 610 correct endpoint for the conference. 612 Two possible approaches to solve this are Identity Assertions and 613 Certificate Fingerprints. 615 5.1. Identity Assertions 617 WebRTC Identity assertion [I-D.ietf-rtcweb-security-arch] is used to 618 bind the identity of the user of the endpoint to the fingerprint of 619 the DTLS-SRTP certificate used for the call. This certificate is 620 unique for a given call and a conference. This allows the Key 621 Distributor to ensure that only authorized users participate in the 622 conference. Similarly the Key Distributor can create a WebRTC 623 Identity assertion to bind the fingerprint of the unique certificate 624 used by the Key Distributor for this conference so that the endpoint 625 can validate it is talking to the correct Key Distributor. Such a 626 setup requires an Identity Provider (Idp) trusted by the endpoints 627 and the Key Distributor. 629 5.2. Certificate Fingerprints in Session Signaling 631 Entities managing session signaling are generally assumed to be 632 untrusted in the PERC framework. However, there are some deployment 633 scenarios where parts of the session signaling may be assumed 634 trustworthy for the purposes of exchanging, in a manner that can be 635 authenticated, the fingerprint of an entity's certificate. 637 As a concrete example, SIP [RFC3261] and Session Description Protocol 638 (SDP) [RFC4566] can be used to convey the fingerprint information per 639 [RFC5763]. An endpoint's SIP User Agent would send an INVITE message 640 containing SDP for the media session along with the endpoint's 641 certificate fingerprint, which can be signed using the procedures 642 described in [RFC8224] for the benefit of forwarding the message to 643 other entities by the Focus [RFC4353]. Other entities can verify the 644 fingerprints match the certificates found in the DTLS-SRTP 645 connections to find the identity of the far end of the DTLS-SRTP 646 connection and verify that is the authorized entity. 648 Ultimately, if using session signaling, an endpoint's certificate 649 fingerprint would need to be securely mapped to a user and conveyed 650 to the Key Distributor so that it can check that that user is 651 authorized. Similarly, the Key Distributor's certificate fingerprint 652 can be conveyed to endpoint in a manner that can be authenticated as 653 being an authorized Key Distributor for this conference. 655 5.3. Conferences Identification 657 The Key Distributor needs to know what endpoints are being added to a 658 given conference. Thus, the Key Distributor and the Media 659 Distributor need to know endpoint-to-conference mappings, which is 660 enabled by exchanging a conference-specific unique identifier defined 661 in [I-D.ietf-perc-dtls-tunnel]. How this unique identifier is 662 assigned is outside the scope of this document. 664 6. PERC Keys 666 This section describes the various keys employed by PERC. 668 6.1. Key Inventory and Management Considerations 670 This section summarizes the several different keys used in the PERC 671 framework, how they are generated, and what purpose they serve. 673 The keys are described in the order in which they would typically be 674 acquired. 676 The various keys used in PERC are shown in Figure 4 below. 678 +-----------+----------------------------------------------------+ 679 | Key | Description | 680 +-----------+----------------------------------------------------+ 681 | KEK | Key shared by all endpoints and used to encrypt | 682 | (EKT Key) | each endpoint's E2E SRTP master key so receiving | 683 | | endpoints can decrypt media. | 684 +-----------+----------------------------------------------------+ 685 | HBH Key | SRTP master key used to encrypt media hop-by-hop. | 686 +-----------+----------------------------------------------------+ 687 | E2E Key | SRTP master key used to encrypt media end-to-end. | 688 +-----------+----------------------------------------------------+ 690 Figure 4: Key Inventory 692 While the number of key types is very small, it should be understood 693 that the actual number of distinct keys can be large as the 694 conference grows in size. 696 As an example, with 1,000 participants in a conference, there would 697 be at least 1,000 distinct SRTP master keys, all of which share the 698 same master salt. Each of those keys are passed through the KDF 699 defined in [RFC3711] to produce the actual encryption and 700 authentication keys. 702 Complicating key management is the fact that the KEK can change and, 703 when it does, the endpoints generate new SRTP master keys that are 704 associated with a new EKT SPI. Endpoints have to retain old keys for 705 a period of time to ensure they can properly decrypt late-arriving or 706 out-of-order packets. 708 A more detailed explanation of each of the keys follows. 710 6.2. DTLS-SRTP Exchange Yields HBH Keys 712 The first set of keys acquired are for hop-by-hop encryption and 713 decryption. Per the Double [I-D.ietf-perc-double] procedures, the 714 endpoint performs DTLS-SRTP exchange with the key distributor and 715 receives a key that is, in fact, "double" the size that is needed. 717 The end-to-end part is the first half of the key, so the endpoint 718 discards that information when generating its own key. The second 719 half of the key material is for hop-by-hop operations, so that half 720 of the key (corresponding to the least significant bits) is assigned 721 internally as the HBH key. 723 The Key Distributor informs the Media Distributor of the HBH key. 724 Specifically, the Key Distributor sends the least significant bits 725 corresponding to the half of the keying material determined through 726 DTLS-SRTP with the endpoint to the Media Distributor. A salt value 727 is generated along with the HBH key. The salt is also longer than 728 needed for hop-by-hop operations, thus only the least significant 729 bits of the required length (i.e., half of the generated salt 730 material) are sent to the Media Distributor. One way to transmit 731 this key and salt information is via the tunnel protocol defined in 732 [I-D.ietf-perc-dtls-tunnel]. 734 No two endpoints have the same HBH key, thus the Media Distributor 735 MUST keep track each distinct HBH key (and the corresponding salt) 736 and use it only for the specified hop. 738 The HBH key is also used for hop-by-hop encryption of RTCP. RTCP is 739 not end-to-end encrypted in PERC. 741 6.3. The Key Distributor Transmits the KEK (EKT Key) 743 Via the aforementioned DTLS-SRTP association, the Key Distributor 744 sends the endpoint the KEK (i.e., EKT Key per 745 [I-D.ietf-perc-srtp-ekt-diet]). This key is known only to the Key 746 Distributor and endpoints. This key is the most important to protect 747 since having knowledge of this key (and the SRTP master salt 748 transmitted as a part of the same message) allows an entity to 749 decrypt any media packet in the conference. 751 Note that the Key Distributor can send any number of EKT Keys to 752 endpoints. This is used to re-key the entire conference. Each key 753 is identified by a "Security Parameter Index" (SPI) value. Endpoints 754 MUST expect that a conference might be re-keyed when a new 755 participant joins a conference or when a participant leaves a 756 conference in order to protect the confidentiality of the 757 conversation before and after such events. 759 The SRTP master salt to be used by the endpoint is transmitted along 760 with the EKT Key. All endpoints in the conference utilize the same 761 SRTP master salt that corresponds with a given EKT Key. 763 The Full EKT Tag in media packets is encrypted using a cipher 764 specified via the EKTKey message (e.g., AES Key Wrap with a 128-bit 765 key). This cipher is different than the cipher used to protect media 766 and is only used to encrypt the endpoint's SRTP master key (and other 767 EKT Tag data as per [I-D.ietf-perc-srtp-ekt-diet]). 769 The media distributor is not given the KEK (i.e., EKT Key). 771 6.4. Endpoints fabricate an SRTP Master Key 773 As stated earlier, the E2E key determined via DTLS-SRTP MAY be 774 discarded in favor of a locally-generated E2E SRTP master key. While 775 the DTLS-SRTP-derived SRTP master key can be used initially, the 776 endpoint might choose to change the SRTP master key periodically and 777 MUST change the SRTP master key as a result of the EKT key changing. 779 A locally-generated SRTP master key is used along with the master 780 salt transmitted to the endpoint from the key distributor via the 781 EKTKey message to encrypt media end-to-end. 783 Since the media distributor is not involved in E2E functions, it does 784 not create this key nor have access to any endpoint's E2E key. Note, 785 too, that even the key distributor is unaware of the locally- 786 generated E2E keys used by each endpoint. 788 The endpoint transmits its E2E key to other endpoints in the 789 conference by periodically including it in SRTP packets in a Full EKT 790 Tag. When placed in the Full EKT Tag, it is encrypted using the EKT 791 Key provided by the key distributor. The master salt is not 792 transmitted, though, since all endpoints receive the same master salt 793 via the EKTKey message from the Key Distributor. The recommended 794 frequency with which an endpoint transmits its SRTP master key is 795 specified in [I-D.ietf-perc-srtp-ekt-diet]. 797 6.5. Summary of Key Types and Entity Possession 799 All endpoints have knowledge of the KEK. 801 Every HBH key is distinct for a given endpoint, thus Endpoint A and 802 Endpoint B do not have knowledge of the other's HBH key. 804 Each endpoint generates its own E2E Key (SRTP master key), thus 805 distinct per endpoint. This key is transmitted (encrypted) via the 806 Full EKT Tag to other endpoints. Endpoints that receive media from a 807 given transmitting endpoint gains knowledge of the transmitter's E2E 808 key via the Full EKT Tag. 810 To summarize the various keys and which entity is in possession of a 811 given key, refer to Figure 5. 813 +----------------------+------------+-------+-------+------------+ 814 | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | 815 +----------------------+------------+-------+-------+------------+ 816 | KEK | Yes | No | No | Yes | 817 +----------------------+------------+-------+-------+------------+ 818 | E2E Key (A and B) | Yes | No | No | Yes | 819 +----------------------+------------+-------+-------+------------+ 820 | HBH Key (A<=>MD X) | Yes | Yes | No | No | 821 +----------------------+------------+-------+-------+------------+ 822 | HBH Key (B<=>MD Y) | No | No | Yes | Yes | 823 +----------------------+------------+---------------+------------+ 824 | HBH Key (MD X<=>MD Y)| No | Yes | Yes | No | 825 +----------------------+------------+---------------+------------+ 827 Figure 5: Keys Types and Entity Possession 829 7. Encrypted Media Packet Format 831 Figure 6 presents a complete picture of what an encrypted media 832 packet per this framework looks like when transmitted over the wire. 833 The packet format shown is encrypted using the Double cryptographic 834 transform with an EKT Tag appended to the end. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++ 839 |V=2|P|X| CC |M| PT | sequence number | IO 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 841 | timestamp | IO 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 843 | synchronization source (SSRC) identifier | IO 844 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO 845 | contributing source (CSRC) identifiers | IO 846 | .... | IO 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 848 | RTP extension (OPTIONAL) ... | |O 849 +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 850 O I | payload ... | IO 851 O I | +-------------------------------+ IO 852 O I | | RTP padding | RTP pad count | IO 853 O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 854 O | | E2E authentication tag | |O 855 O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O 856 O | | OHB ... | |O 857 +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ 858 | | | HBH authentication tag | || 859 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || 860 | | | EKT Tag ... | R || 861 | | +-+-+-+-+-+-+-+-+-+ | || 862 | | +- Neither encrypted nor authenticated; || 863 | | appended after Double is performed || 864 | | || 865 | | || 866 | +- E2E Encrypted Portion E2E Authenticated Portion ---+| 867 | | 868 +--- HBH Encrypted Portion HBH Authenticated Portion ----+ 870 Figure 6: Encrypted Media Packet Format 872 8. Security Considerations 874 8.1. Third Party Attacks 876 On-path attacks are mitigated by hop-by-hop integrity protection and 877 encryption. The integrity protection mitigates packet modification 878 and encryption makes selective blocking of packets harder, but not 879 impossible. 881 Off-path attackers could try connecting to different PERC entities 882 and send specifically crafted packets. Endpoints and Media 883 Distributors mitigate such an attack by performing hop-by-hop 884 authentication and discarding packets that fail authentication. 886 Another attack vector is a third party claiming to be a Media 887 Distributor, fooling endpoints into sending packets to the false 888 Media Distributor instead of the correct one. The deceived sending 889 endpoints could incorrectly assume their packets have been delivered 890 to endpoints when they in fact have not. While this attack is 891 possible, the result is a simple denial of service with no leakage of 892 confidential information, since the false Media Distributor would not 893 have access to either HBH or E2E encryption keys. 895 If mutual DTLS authentication is not employed, a false Media 896 Distributor could cascade to another legitimate Media Distributor 897 that is part of a larger conference. However, this scenario will 898 also produce no positive results for the false Media Distributor 899 since it would not have access to keying material. 901 A third party could cause a denial-of-service by transmitting many 902 bogus or replayed packets toward receiving devices that ultimately 903 degrade conference or device performance. Therefore, implementations 904 might wish to devise mechanisms to safeguard against such 905 illegitimate packets, such as utilizing rate-limiting or performing 906 basic sanity-checks on packets (e.g., looking at packet length or 907 expected sequence number ranges) before performing more expensive 908 decryption operations. 910 8.2. Media Distributor Attacks 912 A malicious or compromised Media Distributor can attack the session 913 in a number of possible ways. 915 8.2.1. Denial of service 917 A simple form of attack is discarding received packets that should be 918 forwarded. This solution framework does not introduce any mitigation 919 for Media Distributors that fail to forward media packets. 921 Another form of attack is modifying received packets before 922 forwarding. With this solution framework, any modification of the 923 end-to-end authenticated data results in the receiving endpoint 924 getting an integrity failure when performing authentication on the 925 received packet. 927 The Media Distributor can also attempt to perform resource 928 consumption attacks on the receiving endpoint. One such attack would 929 be to insert random SSRC/CSRC values in any RTP packet with an inband 930 key-distribution message attached (i.e., Full EKT Tag). Since such a 931 message would trigger the receiver to form a new cryptographic 932 context, the Media Distributor can attempt to consume the receiving 933 endpoints resources. While E2E authentication would fail and the 934 cryptographic context would be destroyed, the key derivation 935 operation would nonetheless consume some computational resources. 936 While resource consumption attacks cannot be mitigated entirely, 937 rate-limiting packets might help reduce the impact of such attacks. 939 8.2.2. Replay Attack 941 A replay attack is when an already received packet from a previous 942 point in the RTP stream is replayed as new packet. This could, for 943 example, allow a Media Distributor to transmit a sequence of packets 944 identified as a user saying "yes", instead of the "no" the user 945 actually said. 947 The mitigation for a replay attack is to implement replay protection 948 as described in Section 3.3.2 of [RFC3711]. End-to-end replay 949 protection MUST be provided for the whole duration of the conference. 951 8.2.3. Delayed Playout Attack 953 The delayed playout attack is a variant of the replay attack. This 954 attack is possible even if E2E replay protection is in place. 955 However, due to fact that the Media Distributor is allowed to select 956 a subset of streams and not forward the rest to a receiver, such as 957 in forwarding only the most active speakers, the receiver has to 958 accept gaps in the E2E packet sequence. The issue with this is that 959 a Media Distributor can select to not deliver a particular stream for 960 a while. 962 Within the window from last packet forwarded to the receiver and the 963 latest received by the Media Distributor, the Media Distributor can 964 select an arbitrary starting point when resuming forwarding packets. 965 Thus what the media source said can be substantially delayed at the 966 receiver with the receiver believing that it is what was said just 967 now, and only delayed due to transport delay. 969 8.2.4. Splicing Attack 971 A splicing attack is an attack where a Media Distributor receiving 972 multiple media sources splices one media stream into the other. If 973 the Media Distributor were able to change the SSRC without the 974 receiver having any method for verifying the original source ID, then 975 the Media Distributor could first deliver stream A and then later 976 forward stream B under the same SSRC as stream A was previously 977 using. By including the SSRC in the integrity check for each packet, 978 both HBH and E2E, PERC prevents splicing attacks. 980 8.2.5. RTCP Attacks 982 PERC does not provide end-to-end protection of RTCP messages. This 983 allows a compromised Media Distributor to impact any message that 984 might be transmitted via RTCP, including media statistics, picture 985 requests, or loss indication. It is also possible for a compromised 986 Media Distributor to forge requests, such as requests to the endpoint 987 to send a new picture. Such requests can consume significant 988 bandwidth and impair conference performance. 990 9. IANA Considerations 992 There are no IANA considerations for this document. 994 10. Acknowledgments 996 The authors would like to thank Mo Zanaty, Christian Oien, and 997 Richard Barnes for invaluable input on this document. Also, we would 998 like to acknowledge Nermeen Ismail for serving on the initial 999 versions of this document as a co-author. We would also like to 1000 acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for 1001 providing some of the text in the document, including much of the 1002 original text in the security considerations section. 1004 11. References 1006 11.1. Normative References 1008 [I-D.ietf-perc-double] 1009 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 1010 Double Encryption Procedures", draft-ietf-perc-double-10 1011 (work in progress), October 2018. 1013 [I-D.ietf-perc-srtp-ekt-diet] 1014 Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. 1015 Andreasen, "Encrypted Key Transport for DTLS and Secure 1016 RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress), 1017 October 2018. 1019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1020 Requirement Levels", BCP 14, RFC 2119, 1021 DOI 10.17487/RFC2119, March 1997, 1022 . 1024 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1025 Jacobson, "RTP: A Transport Protocol for Real-Time 1026 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1027 July 2003, . 1029 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1030 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1031 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1032 . 1034 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1035 Real-time Transport Protocol (SRTP)", RFC 6904, 1036 DOI 10.17487/RFC6904, April 2013, 1037 . 1039 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1040 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1041 May 2017, . 1043 11.2. Informative References 1045 [I-D.ietf-perc-dtls-tunnel] 1046 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 1047 between a Media Distributor and Key Distributor to 1048 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-04 1049 (work in progress), October 2018. 1051 [I-D.ietf-rtcweb-security-arch] 1052 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1053 rtcweb-security-arch-18 (work in progress), February 2019. 1055 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1056 A., Peterson, J., Sparks, R., Handley, M., and E. 1057 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1058 DOI 10.17487/RFC3261, June 2002, 1059 . 1061 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1062 Session Initiation Protocol (SIP)", RFC 4353, 1063 DOI 10.17487/RFC4353, February 2006, 1064 . 1066 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1067 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1068 July 2006, . 1070 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1071 for Establishing a Secure Real-time Transport Protocol 1072 (SRTP) Security Context Using Datagram Transport Layer 1073 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1074 2010, . 1076 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1077 Security (DTLS) Extension to Establish Keys for the Secure 1078 Real-time Transport Protocol (SRTP)", RFC 5764, 1079 DOI 10.17487/RFC5764, May 2010, 1080 . 1082 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 1083 Transport Protocol (RTP) Header Extension for Client-to- 1084 Mixer Audio Level Indication", RFC 6464, 1085 DOI 10.17487/RFC6464, December 2011, 1086 . 1088 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1089 DOI 10.17487/RFC7667, November 2015, 1090 . 1092 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1093 "Authenticated Identity Management in the Session 1094 Initiation Protocol (SIP)", RFC 8224, 1095 DOI 10.17487/RFC8224, February 2018, 1096 . 1098 Authors' Addresses 1100 Paul E. Jones 1101 Cisco 1102 7025 Kit Creek Rd. 1103 Research Triangle Park, North Carolina 27709 1104 USA 1106 Phone: +1 919 476 2048 1107 Email: paulej@packetizer.com 1109 David Benham 1110 Independent 1112 Email: dabenham@gmail.com 1114 Christian Groves 1115 Independent 1116 Melbourne 1117 Australia 1119 Email: cngroves.std@gmail.com