idnits 2.17.1 draft-ietf-perc-private-media-framework-08.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 (January 23, 2019) is 1920 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-17 -- 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: July 27, 2019 C. Groves 6 Independent 7 January 23, 2019 9 A Solution Framework for Private Media in Privacy Enhanced RTP 10 Conferencing 11 draft-ietf-perc-private-media-framework-08 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 July 27, 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 . . . . . . . . . . . . . . . . 4 59 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 5 61 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6 62 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 6 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 . . . 7 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 . . . . . . . . . . . . . 9 70 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 10 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 . . . . . . 13 76 5.3. Conferences Identification . . . . . . . . . . . . . . . 14 77 6. PERC Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. Key Inventory and Management Considerations . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . 20 89 8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 21 90 8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 21 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 95 11.2. Informative References . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 Switched conferencing is an increasingly popular model for multimedia 101 conferences with multiple participants using a combination of audio, 102 video, text, and other media types. With this model, real-time media 103 flows from conference participants are not mixed, transcoded, 104 transrated, recomposed, or otherwise manipulated by a Media 105 Distributor, as might be the case with a traditional media server or 106 multipoint control unit (MCU). Instead, media flows transmitted by 107 conference participants are simply forwarded by Media Distributors to 108 each of the other participants. Media Distributors often forward 109 only a subset of flows based on voice activity detection or other 110 criteria. In some instances, Media Distributors may make limited 111 modifications to RTP [RFC3550] headers, for example, but the actual 112 media content (e.g., voice or video data) is unaltered. 114 An advantage of switched conferencing is that Media Distributors can 115 be more easily deployed on general-purpose computing hardware, 116 including virtualized environments in private and public clouds. 117 While virutalized public cloud environments have been viewed as less 118 secure since resources are not always physically controlled by those 119 who use them and since there are usually several ports open to the 120 public, this draft aims to improve security so as to lower the 121 barrier to taking advantage of those environments. 123 This document defines a solution framework wherein media privacy is 124 ensured by making it impossible for a media distributor to gain 125 access to keys needed to decrypt or authenticate the actual media 126 content sent between conference participants. At the same time, the 127 framework allows for the Media Distributors to modify certain RTP 128 headers; add, remove, encrypt, or decrypt RTP header extensions; and 129 encrypt and decrypt RTCP packets. The framework also prevents replay 130 attacks by authenticating each packet transmitted between a given 131 participant and the media distributor using a unique key per endpoint 132 that is independent from the key for media encryption and 133 authentication. 135 A goal of this document is to define a framework for enhanced privacy 136 in RTP-based conferencing environments while utilizing existing 137 security procedures defined for RTP with minimal enhancements. 139 2. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Additionally, this solution framework uses the following terms and 148 acronyms: 150 End-to-End (E2E): Communications from one endpoint through one or 151 more Media Distributors to the endpoint at the other end. 153 Hop-by-Hop (HBH): Communications between an endpoint and a Media 154 Distributor or between Media Distributors. 156 Trusted Endpoint: An RTP flow terminating entity that has possession 157 of E2E media encryption keys and terminates E2E encryption. This may 158 include embedded user conferencing equipment or browsers on 159 computers, media gateways, MCUs, media recording device and more that 160 are in the trusted domain for a given deployment. 162 Media Distributor (MD): An RTP middlebox that forwards endpoint media 163 content (e.g., voice or video data) unaltered, either a subset or all 164 of the flows at any given time, and is never allowed have access to 165 E2E encryption keys. It operates according to the Selective 166 Forwarding Middlebox RTP topologies [RFC7667] per the constraints 167 defined by the PERC system, which includes, but not limited to, 168 having no access to RTP media unencrypted and having limits on what 169 RTP header field it can alter. 171 Key Distributor: An entity that is a logical function which 172 distributes keying material and related information to trusted 173 endpoints and Media Distributor(s), only that which is appropriate 174 for each. The Key Distributor might be co-resident with another 175 entity trusted with E2E keying material. 177 Conference: Two or more participants communicating via trusted 178 endpoints to exchange RTP flows through one or more Media 179 Distributor. 181 Call Processing: All trusted endpoints in the conference connect to 182 it by a call processing dialog, such as with the Focus defined in the 183 Framework for Conferencing with SIP [RFC4353]. 185 Third Party: Any entity that is not an Endpoint, Media Distributor, 186 Key Distributor or Call Processing entity as described in this 187 document. 189 3. PERC Entities and Trust Model 191 The following figure depicts the trust relationships, direct or 192 indirect, between entities described in the subsequent sub-sections. 193 Note that these entities may be co-located or further divided into 194 multiple, separate physical devices. 196 Please note that some entities classified as untrusted in the simple, 197 general deployment scenario used most commonly in this document might 198 be considered trusted in other deployments. This document does not 199 preclude such scenarios, but keeps the definitions and examples 200 focused by only using the the simple, most general deployment 201 scenario. 203 | 204 +----------+ | +-----------------+ 205 | Endpoint | | | Call Processing | 206 +----------+ | +-----------------+ 207 | 208 | 209 +----------------+ | +--------------------+ 210 | Key Distributor| | | Media Distributor | 211 +----------------+ | +--------------------+ 212 | 213 Trusted | Untrusted 214 Entities | Entities 215 | 217 Figure 1: Trusted and Untrusted Entities in PERC 219 3.1. Untrusted Entities 221 The architecture described in this framework document enables 222 conferencing infrastructure to be hosted in domains, such as in a 223 cloud conferencing provider's facilities, where the trustworthiness 224 is below the level needed to assume the privacy of participant's 225 media is not compromised. The conferencing infrastructure in such a 226 domain is still trusted with reliably connecting the participants 227 together in a conference, but not trusted with keying material needed 228 to decrypt any of the participant's media. Entities in such lower 229 trustworthiness domains are referred to as untrusted entities from 230 this point forward. 232 It is important to understand that untrusted in this document does 233 not mean an entity is not expected to function properly. Rather, it 234 means only that the entity does not have access to the E2E media 235 encryption keys. 237 3.1.1. Media Distributor 239 A Media Distributor forwards RTP flows between endpoints in the 240 conference while performing per-hop authentication of each RTP 241 packet. The Media Distributor may need access to one or more RTP 242 headers or header extensions, potentially adding or modifying a 243 certain subset. The Media Distributor also relays secured messaging 244 between the endpoints and the Key Distributor and acquires per-hop 245 key information from the Key Distributor. The actual media content 246 must not be decryptable by a Media Distributor, as it is untrusted to 247 have access to the E2E media encryption keys. The key exchange 248 mechanisms specified in this framework prevents the Media Distributor 249 from gaining access to the E2E media encryption keys. 251 An endpoint's ability to connect to a conference serviced by a Media 252 Distributor does imply that the endpoint is authorized to have access 253 to the E2E media encryption keys, as the Media Distributor does not 254 have the ability to determine whether an endpoint is authorized. 255 Instead, the Key Distributor is responsible for authenticating the 256 endpoint (e.g., using WebRTC Identity 257 [I-D.ietf-rtcweb-security-arch]) and determining its authorization to 258 receive E2E and HBH media encryption keys. 260 A Media Distributor must perform its role in properly forwarding 261 media packets while taking measures to mitigate the adverse effects 262 of denial of service attacks (refer to Section 8) to a level equal to 263 or better than traditional conferencing (i.e. non-PERC) deployments. 265 A Media Distributor or associated conferencing infrastructure may 266 also initiate or terminate various conference control related 267 messaging, which is outside the scope of this framework document. 269 3.1.2. Call Processing 271 The call processing function is untrusted in the simple, general 272 deployment scenario. When a physical subset of the call processing 273 function resides in facilities outside the trusted domain, it should 274 not be trusted to have access to E2E key information. 276 The call processing function may include the processing of call 277 signaling messages, as well as the signing of those messages. It may 278 also authenticate the endpoints for the purpose of call signaling and 279 subsequently joining of a conference hosted through one or more Media 280 Distributors. Call processing may optionally ensure the privacy of 281 call signaling messages between itself, the endpoint, and other 282 entities. 284 3.2. Trusted Entities 286 From the PERC model system perspective, entities considered trusted 287 (refer to Figure 1) can be in possession of the E2E media encryption 288 keys for one or more conferences. 290 3.2.1. Endpoint 292 An endpoint is considered trusted and has access to E2E key 293 information. While it is possible for an endpoint to be compromised, 294 subsequently performing in undesired ways, defining endpoint 295 resistance to compromise is outside the scope of this document. 296 Endpoints take measures to mitigate the adverse effects of denial of 297 service attacks (refer to Section 8) from other entities, including 298 from other endpoints, to a level equal to or better than traditional 299 conference (i.e., non-PERC) deployments. 301 3.2.2. Key Distributor 303 The Key Distributor, which may be colocated with an endpoint or exist 304 standalone, is responsible for providing key information to endpoints 305 for both end-to-end (E2E) and hop-by-hop (HBH) security and for 306 providing key information to Media Distributors for the hop-by-hop 307 security. 309 Interaction between the Key Distributor and the call processing 310 function is necessary to for proper conference-to-endpoint mappings. 311 This is described in Section 5.3. 313 The Key Distributor needs to be secured and managed in a way to 314 prevent exploitation by an adversary, as any kind of compromise of 315 the Key Distributor puts the security of the conference at risk. 317 4. Framework for PERC 319 The purpose for this framework is to define a means through which 320 media privacy is ensured when communicating within a conferencing 321 environment consisting of one or more Media Distributors that only 322 switch, hence not terminate, media. It does not otherwise attempt to 323 hide the fact that a conference between endpoints is taking place. 325 This framework reuses several specified RTP security technologies, 326 including SRTP [RFC3711], EKT [I-D.ietf-perc-srtp-ekt-diet], and 327 DTLS-SRTP [RFC5764]. 329 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 331 This solution framework focuses on the end-to-end privacy and 332 integrity of the participant's media by limiting access to only 333 trusted entities to the E2E key used for authenticated end-to-end 334 encryption. However, this framework does give a Media Distributor 335 access to RTP headers and all or most header extensions, as well as 336 the ability to modify a certain subset of those headers and to add 337 header extensions. Packets received by a Media Distributor or an 338 endpoint are authenticated hop-by-hop. 340 To enable all of the above, this framework defines the use of two 341 security contexts and two associated encryption keys: an "inner" key 342 (an E2E key distinct for each transmitted media flow) for 343 authenticated encryption of RTP media between endpoints and an 344 "outer" key (HBH key) known only to Media Distributor and the 345 adjacent endpoint) for the hop between an endpoint and a Media 346 Distributor or between Media Distributor. 348 +-------------+ +-------------+ 349 | |################################| | 350 | Media |------------------------ *----->| Media | 351 | Distributor |<----------------------*-|------| Distributor | 352 | X |#####################*#|#|######| Y | 353 | | | | | | | 354 +-------------+ | | | +-------------+ 355 # ^ | # HBH Key (XY) -+ | | # ^ | # 356 # | | # E2E Key (B) ---+ | # | | # 357 # | | # E2E Key (A) -----+ # | | # 358 # | | # # | | # 359 # | | # # | | # 360 # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # 361 # | | # # | | # 362 # *--------- E2E Key (A) E2E Key (A) ---------* # 363 # | *------- E2E Key (B) E2E Key (B) -------* | # 364 # | | # # | | # 365 # | v # # | v # 366 +-------------+ +-------------+ 367 | Endpoint A | | Endpoint B | 368 +-------------+ +-------------+ 370 Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP 371 Packets 373 The Double transform [I-D.ietf-perc-double] enables endpoints to 374 perform encryption using both the end-to-end and hop-by-hop contexts 375 while still preserving the same overall interface as other SRTP 376 transforms. The Media Distributor simply uses the corresponding 377 normal (single) AES-GCM transform, keyed with the appropriate HBH 378 keys. See Section 6.1 for a description of the keys used in PERC and 379 Section 7 for diagram of how encrypted RTP packets appear on the 380 wire. 382 RTCP is only encrypted hop-by-hop, not end-to-end. This framework 383 introduces no additional step for RTCP authenticated encryption, so 384 the procedures needed are specified in [RFC3711] and use the same 385 outer, hop-by-hop cryptographic context chosen in the Double 386 operation described above. 388 4.2. E2E Key Confidentiality 390 To ensure the confidentiality of E2E keys shared between endpoints, 391 endpoints use a common Key Encryption Key (KEK) that is known only by 392 the trusted entities in a conference. That KEK, defined in the EKT 393 [I-D.ietf-perc-srtp-ekt-diet] specification as the EKT Key, is used 394 to subsequently encrypt the SRTP master key used for E2E 395 authenticated encryption of media sent by a given endpoint. Each 396 endpoint in the conference creates an SRTP master key for E2E 397 authenticated encryption and keep track of the E2E keys received via 398 the Full EKT Tag for each distinct synchronization source (SSRC) in 399 the conference so that it can properly decrypt received media. An 400 endpoint may change its E2E key at any time and advertise that new 401 key to the conference as specified in [I-D.ietf-perc-srtp-ekt-diet]. 403 4.3. E2E Keys and Endpoint Operations 405 Any given RTP media flow is identified by its SSRC, and an endpoint 406 might send more than one at a time and change the mix of media flows 407 transmitted during the life of a conference. 409 Thus, an endpoint MUST maintain a list of SSRCs from received RTP 410 flows and each SSRC's associated E2E key information. An endpoint 411 MUST discard old E2E keys no later than when it leaves the conference 412 (see Section 4.5.2). 414 If there is a need to encrypt one or more RTP header extensions end- 415 to-end, the endpoint derives an encryption key from the E2E SRTP 416 master key to encrypt header extensions as per [RFC6904]. The Media 417 Distributor is unable use the information contained in those header 418 extensions encrypted with an E2E key. 420 4.4. HBH Keys and Per-hop Operations 422 To ensure the integrity of transmitted media packets, it is REQUIRED 423 that every packet be authenticated hop-by-hop between an endpoint and 424 a Media Distributor, as well between Media Distributors. The 425 authentication key used for hop-by-hop authentication is derived from 426 an SRTP master key shared only on the respective hop. Each HBH key 427 is distinct per hop and no two hops ever use the same SRTP master 428 key. 430 While endpoints also perform HBH authentication, the ability of the 431 endpoints to reconstruct the original RTP header also enables the 432 endpoints to authenticate RTP packets E2E. This design yields 433 flexibility to the Media Distributor to change certain RTP header 434 values as packets are forwarded. Which values the Media Distributor 435 can change in the RTP header are defined in [I-D.ietf-perc-double]. 436 RTCP can only be encrypted hop-by-hop, giving the Media Distributor 437 the flexibility to forward RTCP content unchanged, transmit compound 438 RTCP packets or to initiate RTCP packets for reporting statistics or 439 conveying other information. Performing hop-by-hop authentication 440 for all RTP and RTCP packets also helps provide replay protection 441 (see Section 8). 443 If there is a need to encrypt one or more RTP header extensions hop- 444 by-hop, the endpoint derives an encryption key from the HBH SRTP 445 master key to encrypt header extensions as per [RFC6904]. This still 446 gives the Media Distributor visibility into header extensions, such 447 as the one used to determine audio level [RFC6464] of conference 448 participants. Note that when RTP header extensions are encrypted, 449 all hops need to decrypt and re-encrypt these encrypted header 450 extensions. 452 4.5. Key Exchange 454 In brief, the keys used by any given endpoints are determined in the 455 following way: 457 o The HBH keys that the endpoint uses to send and receive SRTP media 458 are derived from a DTLS handshake that the endpoint performs with 459 the Key Distributor (following normal DTLS-SRTP procedures). 461 o The E2E key that an endpoint uses to send SRTP media can either be 462 set from DTLS or chosen by the endpoint. It is then distributed 463 to other endpoints in a Full EKT Tag, encrypted under an EKT Key 464 provided to the client by the Key Distributor within the DTLS 465 channel they negotiated. 467 o Each E2E key that an endpoint uses to receive SRTP media is set by 468 receiving a Full EKT Tag from another endpoint. 470 4.5.1. Initial Key Exchange and Key Distributor 472 The Media Distributor maintains a tunnel with the Key Distributor 473 (e.g., using [I-D.ietf-perc-dtls-tunnel]), making it possible for the 474 Media Distributor to facilitate the establishment of a secure DTLS 475 association between each endpoint and the Key Distributor as shown 476 the following figure. The DTLS association between endpoints and the 477 Key Distributor enables each endpoint to generate E2E and HBH keys 478 and receive the Key Encryption Key (KEK) (i.e., EKT Key). At the 479 same time, the Key Distributor securely provides the HBH key 480 information to the Media Distributor. The key information summarized 481 here may include the SRTP master key, SRTP master salt, and the 482 negotiated cryptographic transform. 484 +-----------+ 485 KEK info | Key | HBH Key info to 486 to Endpoints |Distributor| Endpoints & Media Distributor 487 +-----------+ 488 # ^ ^ # 489 # | | #--- Tunnel 490 # | | # 491 +-----------+ +-----------+ +-----------+ 492 | Endpoint | DTLS | Media | DTLS | Endpoint | 493 | KEK |<------------|Distributor|------------>| KEK | 494 | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | 495 +-----------+ +-----------+ +-----------+ 497 Figure 3: Exchanging Key Information Between Entities 499 In addition to the secure tunnel between the Media Distributor and 500 the Key Distributor, there are two additional types of security 501 associations utilized as a part of the key exchange as discussed in 502 the following paragraphs. One is a DTLS-SRTP association between an 503 endpoint and the Key Distributor (with packets passing through the 504 Media Distributor) and the other is a DTLS-SRTP association between 505 peer Media Distributors. 507 Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP 508 session's media ports for the purposes of key information exchange 509 with the Key Distributor. The Media Distributor does not terminate 510 the DTLS signaling, but instead forwards DTLS packets received from 511 an endpoint on to the Key Distributor (and vice versa) via a tunnel 512 established between Media Distributor and the Key Distributor. 514 In establishing the DTLS association between endpoints and the Key 515 Distributor, the endpoint MUST act as the DTLS client and the Key 516 Distributor MUST act as the DTLS server. The Key Encryption Key 517 (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the 518 DTLS association to endpoints via procedures defined in EKT 519 [I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message. 521 The Key Distributor MUST NOT establish DTLS-SRTP associations with 522 endpoints without first authenticating the Media Distributor 523 tunneling the DTLS-SRTP packets from the endpoint. 525 Note that following DTLS-SRTP procedures for the 526 [I-D.ietf-perc-double] cipher, the endpoint generates both E2E and 527 HBH encryption keys and salt values. Endpoints MUST either use the 528 DTLS-SRTP generated E2E key for transmission or generate a fresh E2E 529 key. In either case, the generated SRTP master salt for E2E 530 encryption MUST be replaced with the salt value provided by the Key 531 Distributor via the EKTKey message. That is because every endpoint 532 in the conference uses the same SRTP master salt. The endpoint only 533 transmits the SRTP master key (not the salt) used for E2E encryption 534 to other endpoints in RTP/RTCP packets per 535 [I-D.ietf-perc-srtp-ekt-diet]. 537 Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media 538 Distributor to establish the HBH key for transmitting RTP and RTCP 539 packets to that peer Media Distributor. The Key Distributor does not 540 facilitate establishing a HBH key for use between Media Distributors. 542 4.5.2. Key Exchange during a Conference 544 Following the initial key information exchange with the Key 545 Distributor, an endpoint is able to encrypt media end-to-end with an 546 E2E key, sending that E2E key to other endpoints encrypted with the 547 KEK, and is able to encrypt and authenticate RTP packets using a HBH 548 key. The procedures defined do not allow the Media Distributor to 549 gain access to the KEK information, preventing it from gaining access 550 to any endpoint's E2E key and subsequently decrypting media. 552 The KEK (i.e., EKT Key) may need to change from time-to-time during 553 the life of a conference, such as when a new participant joins or 554 leaves a conference. Dictating if, when or how often a conference is 555 to be re-keyed is outside the scope of this document, but this 556 framework does accommodate re-keying during the life of a conference. 558 When a Key Distributor decides to re-key a conference, it transmits a 559 new EKTKey message [I-D.ietf-perc-srtp-ekt-diet] to each of the 560 conference participants containing the new EKT Key. Upon receipt of 561 the new EKT Key, the endpoint MUST create a new SRTP master key and 562 prepare to send that key inside a Full EKT Field using the new EKT 563 Key as per Section 4.5 of [I-D.ietf-perc-srtp-ekt-diet]. In order to 564 allow time for all endpoints in the conference to receive the new 565 keys, the sender should follow the recommendations in Section 4.7 of 566 [I-D.ietf-perc-srtp-ekt-diet]. On receiving a new EKT Key, endpoints 567 MUST be prepared to decrypt EKT tags using the new key. The EKT SPI 568 field is used to differentiate between tags encrypted with the old 569 and new keys. 571 After re-keying, an endpoint SHOULD retain prior SRTP master keys and 572 EKT Key for a period of time sufficient for the purpose of ensuring 573 it can decrypt late-arriving or out-of-order packets or packets sent 574 by other endpoints that used the prior keys for a period of time 575 after re-keying began. An endpoint MAY retain old keys until the end 576 of the conference. 578 Endpoints MAY follow the procedures in section 5.2 of [RFC5764] to 579 renegotiate HBH keys as desired. If new HBH keys are generated, the 580 new keys are also delivered to the Media Distributor following the 581 procedures defined in [I-D.ietf-perc-dtls-tunnel] as one possible 582 method. 584 Endpoints MAY change the E2E encryption key used at any time. 585 Endpoints MUST generate a new E2E encryption key whenever it receives 586 a new EKT Key. After switching to a new key, the new key is conveyed 587 to other endpoints in the conference in RTP/RTCP packets per 588 [I-D.ietf-perc-srtp-ekt-diet]. 590 5. Authentication 592 It is important to this solution framework that the entities can 593 validate the authenticity of other entities, especially the Key 594 Distributor and endpoints. The details of this are outside the scope 595 of specification but a few possibilities are discussed in the 596 following sections. The key requirements are that an endpoint can 597 verify it is connected to the correct Key Distributor for the 598 conference and the Key Distributor can verify the endpoint is the 599 correct endpoint for the conference. 601 Two possible approaches to solve this are Identity Assertions and 602 Certificate Fingerprints. 604 5.1. Identity Assertions 606 WebRTC Identity assertion [I-D.ietf-rtcweb-security-arch] is used to 607 bind the identity of the user of the endpoint to the fingerprint of 608 the DTLS-SRTP certificate used for the call. This certificate is 609 unique for a given call and a conference. This allows the Key 610 Distributor to ensure that only authorized users participate in the 611 conference. Similarly the Key Distributor can create a WebRTC 612 Identity assertion to bind the fingerprint of the unique certificate 613 used by the Key Distributor for this conference so that the endpoint 614 can validate it is talking to the correct Key Distributor. Such a 615 setup requires an Identity Provider (Idp) trusted by the endpoints 616 and the Key Distributor. 618 5.2. Certificate Fingerprints in Session Signaling 620 Entities managing session signaling are generally assumed to be 621 untrusted in the PERC framework. However, there are some deployment 622 scenarios where parts of the session signaling may be assumed 623 trustworthy for the purposes of exchanging, in a manner that can be 624 authenticated, the fingerprint of an entity's certificate. 626 As a concrete example, SIP [RFC3261] and SDP [RFC4566] can be used to 627 convey the fingerprint information per [RFC5763]. An endpoint's SIP 628 User Agent would send an INVITE message containing SDP for the media 629 session along with the endpoint's certificate fingerprint, which can 630 be signed using the procedures described in [RFC8224] for the benefit 631 of forwarding the message to other entities by the Focus [RFC4353]. 632 Other entities can verify the fingerprints match the certificates 633 found in the DTLS-SRTP connections to find the identity of the far 634 end of the DTLS-SRTP connection and verify that is the authorized 635 entity. 637 Ultimately, if using session signaling, an endpoint's certificate 638 fingerprint would need to be securely mapped to a user and conveyed 639 to the Key Distributor so that it can check that that user is 640 authorized. Similarly, the Key Distributor's certificate fingerprint 641 can be conveyed to endpoint in a manner that can be authenticated as 642 being an authorized Key Distributor for this conference. 644 5.3. Conferences Identification 646 The Key Distributor needs to know what endpoints are being added to a 647 given conference. Thus, the Key Distributor and the Media 648 Distributor need to know endpoint-to-conference mappings, which is 649 enabled by exchanging a conference-specific unique identifier defined 650 in [I-D.ietf-perc-dtls-tunnel]. How this unique identifier is 651 assigned is outside the scope of this document. 653 6. PERC Keys 655 This section describes the various keys employed by PERC, how they 656 are derived, conveyed, and so forth. 658 6.1. Key Inventory and Management Considerations 660 This section summarizes the several different keys used in the PERC 661 framework, how they are generated, and what purpose they serve. 663 The keys are described in the order in which they would typically be 664 acquired. 666 The various keys used in PERC are shown in Figure 4 below. 668 +-----------+----------------------------------------------------+ 669 | Key | Description | 670 +-----------+----------------------------------------------------+ 671 | KEK | Key shared by all endpoints and used to encrypt | 672 | (EKT Key) | each endpoint's SRTP master key so receiving | 673 | | endpoints can decrypt media. | 674 +-----------+----------------------------------------------------+ 675 | HBH Key | Key used to encrypt media hop-by-hop. | 676 +-----------+----------------------------------------------------+ 677 | E2E Key | Key used to encrypt media end-to-end. | 678 +-----------+----------------------------------------------------+ 680 Figure 4: Key Inventory 682 While the number key types is very small, it should be understood 683 that the actual number of distinct keys can be large as the 684 conference grows in size. 686 As an example, with 1,000 participants in a conference, there would 687 be at least 1,000 distinct SRTP master keys, all of which share the 688 same master salt. Each of those keys are passed through the KDF 689 defined in [RFC3711] to produce the actual encryption and 690 authentication keys. 692 Complicating key management is the fact that the KEK can change and, 693 when it does, the endpoints generate new SRTP master keys that are 694 associated with a new EKT SPI. Endpoints have to retain old keys for 695 a period of time to ensure they can properly decrypt late-arriving or 696 out-of-order packets. 698 A more detailed explanation of each of the keys follows. 700 6.2. DTLS-SRTP Exchange Yields HBH Keys 702 The first set of keys acquired are for hop-by-hop encryption and 703 decryption. Per the Double [I-D.ietf-perc-double] procedures, the 704 endpoint performs DTLS-SRTP exchange with the key distributor and 705 receives a key that is, in fact, "double" the size that is needed. 706 The end-to-end part is the first half of the key, so the endpoint 707 discards that information when generating its own key. The second 708 half of the key material is for hop-by-hop operations, so that half 709 of the key (corresponding to the least significant bits) is assigned 710 internally as the HBH key. 712 The Key Distributor informs the Media Distributor of the HBH key. 713 Specifically, the Key Distributor sends the least significant bits 714 corresponding to the half of the keying material determined through 715 DTLS-SRTP with the endpoint to the Media Distributor. A salt value 716 is generated along with the HBH key. The salt is also longer than 717 needed for hop-by-hop operations, thus only the least significant 718 bits of the required length (i.e., half of the generated salt 719 material) are sent to the Media Distributor. One way to transmit 720 this key and salt information is via the tunnel protocol defined in 721 [I-D.ietf-perc-dtls-tunnel]. 723 No two endpoints have the same HBH key, thus the Media Distributor 724 MUST keep track each distinct HBH key (and the corresponding salt) 725 and use it only for the specified hop. 727 The HBH key is also used for hop-by-hop encryption of RTCP. RTCP is 728 not end-to-end encrypted in PERC. 730 6.3. The Key Distributor Transmits the KEK (EKT Key) 732 Via the aforementioned DTLS-SRTP association, the Key Distributor 733 sends the endpoint the KEK (i.e., EKT Key per 734 [I-D.ietf-perc-srtp-ekt-diet]). This key is known only to the Key 735 Distributor and endpoints. This key is the most important to protect 736 since having knowledge of this key (and the SRTP master salt 737 transmitted as a part of the same message) allows an entity to 738 decrypt any media packet in the conference. 740 Note that the Key Distributor can send any number of EKT Keys to 741 endpoints. This is used to re-key the entire conference. Each key 742 is identified by a "Security Parameter Index" (SPI) value. Endpoints 743 MUST expect that a conference might be re-keyed when a new 744 participant joins a conference or when a participant leaves a 745 conference in order to protect the confidentiality of the 746 conversation before and after such events. 748 The SRTP master salt to be used by the endpoint is transmitted along 749 with the EKT Key. All endpoints in the conference utilize the same 750 SRTP master salt that corresponds with a given EKT Key. 752 The Full EKT Tag in media packets is encrypted using a cipher 753 specified via the EKTKey message (e.g., AES Key Wrap with a 128-bit 754 key). This cipher is different than the cipher used to protect media 755 and is only used to encrypt the endpoint's SRTP master key (and other 756 EKT Tag data as per [I-D.ietf-perc-srtp-ekt-diet]). 758 The media distributor is not given the KEK (i.e., EKT Key). 760 6.4. Endpoints fabricate an SRTP Master Key 762 As stated earlier, the E2E key determined via DTLS-SRTP MAY be 763 discarded in favor of a locally-generated SRTP master key. While the 764 DTLS-SRTP-derived SRTP master key can be used initially, the endpoint 765 might choose to change the SRTP master key periodically and MUST 766 change the SRTP master key as a result of the EKT key changing. 768 A locally-generated SRTP master key is used along with the master 769 salt transmitted to the endpoint from the key distributor via the 770 EKTKey message to encrypt media end-to-end. 772 Since the media distributor is not involved in E2E functions, it does 773 not create this key nor have access to any endpoint's E2E key. Note, 774 too, that even the key distributor is unaware of the locally- 775 generated E2E keys used by each endpoint. 777 The endpoint transmits its E2E key to other endpoints in the 778 conference by periodically including it in SRTP packets in a Full EKT 779 Tag. When placed in the Full EKT Tag, it is encrypted using the EKT 780 Key provided by the key distributor. The master salt is not 781 transmitted, though, since all endpoints receive the same master salt 782 via the EKTKey message from the Key Distributor. The recommended 783 frequency with which an endpoint transmits its SRTP master key is 784 specified in [I-D.ietf-perc-srtp-ekt-diet]. 786 6.5. Summary of Key Types and Entity Possession 788 All endpoints have knowledge of the KEK. 790 Every HBH key is distinct for a given endpoint, thus Endpoint A and 791 Endpoint B do not have knowledge of the other's HBH key. 793 Each endpoint generates its own E2E Key (SRTP master key), thus 794 distinct per endpoint. This key is transmitted (encrypted) via the 795 Full EKT Tag to other endpoints. Endpoints that receive media from a 796 given transmitting endpoint gains knowledge of the transmitter's E2E 797 key via the Full EKT Tag. 799 To summarize the various keys and which entity is in possession of a 800 given key, refer to Figure 5. 802 +----------------------+------------+-------+-------+------------+ 803 | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | 804 +----------------------+------------+-------+-------+------------+ 805 | KEK | Yes | No | No | Yes | 806 +----------------------+------------+-------+-------+------------+ 807 | E2E Key (A and B) | Yes | No | No | Yes | 808 +----------------------+------------+-------+-------+------------+ 809 | HBH Key (A<=>MD X) | Yes | Yes | No | No | 810 +----------------------+------------+-------+-------+------------+ 811 | HBH Key (B<=>MD Y) | No | No | Yes | Yes | 812 +----------------------+------------+---------------+------------+ 813 | HBH Key (MD X<=>MD Y)| No | Yes | Yes | No | 814 +----------------------+------------+---------------+------------+ 816 Figure 5: Keys Types and Entity Possession 818 7. Encrypted Media Packet Format 820 Figure 6 presents a complete picture of what an encrypted media 821 packet per this framework looks like when transmitted over the wire. 822 The packet format shown is encrypted using the Double cryptographic 823 transform with an EKT Tag appended to the end. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++ 828 |V=2|P|X| CC |M| PT | sequence number | IO 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 830 | timestamp | IO 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 832 | synchronization source (SSRC) identifier | IO 833 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO 834 | contributing source (CSRC) identifiers | IO 835 | .... | IO 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 837 | RTP extension (OPTIONAL) ... | |O 838 +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 839 O I | payload ... | IO 840 O I | +-------------------------------+ IO 841 O I | | RTP padding | RTP pad count | IO 842 O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 843 O | | E2E authentication tag | |O 844 O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O 845 O | | OHB ... | |O 846 +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ 847 | | | HBH authentication tag | || 848 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || 849 | | | EKT Tag ... | R || 850 | | +-+-+-+-+-+-+-+-+-+ | || 851 | | +- Neither encrypted nor authenticated; || 852 | | appended after Double is performed || 853 | | || 854 | | || 855 | +- E2E Encrypted Portion E2E Authenticated Portion ---+| 856 | | 857 +--- HBH Encrypted Portion HBH Authenticated Portion ----+ 859 Figure 6: Encrypted Media Packet Format 861 8. Security Considerations 863 8.1. Third Party Attacks 865 On-path attacks are mitigated by hop-by-hop integrity protection and 866 encryption. The integrity protection mitigates packet modification 867 and encryption makes selective blocking of packets harder, but not 868 impossible. 870 Off-path attackers may try connecting to different PERC entities and 871 send specifically crafted packets. A successful attacker might be 872 able to get the Media Distributor to forward such packets. The Media 873 Distributor mitigates such an attack by performing hop-by-hop 874 authentication and discarding packets that fail authentication. 876 Another potential attack is a third party claiming to be a Media 877 Distributor, fooling endpoints in to sending packets to the false 878 Media Distributor instead of the correct one. The deceived sending 879 endpoints could incorrectly assuming their packets have been 880 delivered to endpoints when they in fact have not. Further, the 881 false Media Distributor may cascade to another legitimate Media 882 Distributor creating a false version of the real conference. 884 This attack is be mitigated by the false Media Distributor not being 885 authenticated by the Key Distributor. They Key Distributor will fail 886 to establish the secure association with the endpoint if the Media 887 Distributor cannot be authenticated. 889 8.2. Media Distributor Attacks 891 The Media Distributor can attack the session in a number of possible 892 ways. 894 8.2.1. Denial of service 896 A simple form of attack is discarding received packets that should be 897 forwarded. This solution framework does not introduce any mitigation 898 for Media Distributors that fail to forward media packets. 900 Another form of attack is modifying received packets before 901 forwarding. With this solution framework, any modification of the 902 end-to-end authenticated data results in the receiving endpoint 903 getting an integrity failure when performing authentication on the 904 received packet. 906 The Media Distributor can also attempt to perform resource 907 consumption attacks on the receiving endpoint. One such attack would 908 be to insert random SSRC/CSRC values in any RTP packet with an inband 909 key-distribution message attached (i.e., Full EKT Tag). Since such a 910 message would trigger the receiver to form a new cryptographic 911 context, the Media Distributor can attempt to consume the receiving 912 endpoints resources. While E2E authentication would fail and the 913 cryptographic context would be destroyed, the key derivation 914 operation would nonetheless consume some computational resources. 916 8.2.2. Replay Attack 918 A replay attack is when an already received packets from a previous 919 point in the RTP stream is replayed as new packet. This could, for 920 example, allow a Media Distributor to transmit a sequence of packets 921 identified as a user saying "yes", instead of the "no" the user 922 actually said. 924 The mitigation for a replay attack is to prevent old packets beyond a 925 small-to-modest jitter and network re-ordering sized window to be 926 rejected. End-to-end replay protection MUST be provided for the 927 whole duration of the conference. 929 8.2.3. Delayed Playout Attack 931 The delayed playout attack is a variant of the replay attack. This 932 attack is possible even if E2E replay protection is in place. 933 However, due to fact that the Media Distributor is allowed to select 934 a sub-set of streams and not forward the rest to a receiver, such as 935 in forwarding only the most active speakers, the receiver has to 936 accept gaps in the E2E packet sequence. The issue with this is that 937 a Media Distributor can select to not deliver a particular stream for 938 a while. 940 Within the window from last packet forwarded to the receiver and the 941 latest received by the Media Distributor, the Media Distributor can 942 select an arbitrary starting point when resuming forwarding packets. 943 Thus what the media source said can be substantially delayed at the 944 receiver with the receiver believing that it is what was said just 945 now, and only delayed due to transport delay. 947 8.2.4. Splicing Attack 949 The splicing attack is an attack where a Media Distributor receiving 950 multiple media sources splices one media stream into the other. If 951 the Media Distributor is able to change the SSRC without the receiver 952 having any method for verifying the original source ID, then the 953 Media Distributor could first deliver stream A and then later forward 954 stream B under the same SSRC as stream A was previously using. By 955 not allowing the Media Distributor to change the SSRC, PERC mitigates 956 this attack. 958 9. IANA Considerations 960 There are no IANA considerations for this document. 962 10. Acknowledgments 964 The authors would like to thank Mo Zanaty and Christian Oien for 965 invaluable input on this document. Also, we would like to 966 acknowledge Nermeen Ismail for serving on the initial versions of 967 this document as a co-author. 969 11. References 971 11.1. Normative References 973 [I-D.ietf-perc-double] 974 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 975 Double Encryption Procedures", draft-ietf-perc-double-10 976 (work in progress), October 2018. 978 [I-D.ietf-perc-srtp-ekt-diet] 979 Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. 980 Andreasen, "Encrypted Key Transport for DTLS and Secure 981 RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress), 982 October 2018. 984 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 985 Requirement Levels", BCP 14, RFC 2119, 986 DOI 10.17487/RFC2119, March 1997, 987 . 989 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 990 Jacobson, "RTP: A Transport Protocol for Real-Time 991 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 992 July 2003, . 994 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 995 Real-time Transport Protocol (SRTP)", RFC 6904, 996 DOI 10.17487/RFC6904, April 2013, 997 . 999 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1000 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1001 May 2017, . 1003 11.2. Informative References 1005 [I-D.ietf-perc-dtls-tunnel] 1006 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 1007 between a Media Distributor and Key Distributor to 1008 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-04 1009 (work in progress), October 2018. 1011 [I-D.ietf-rtcweb-security-arch] 1012 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1013 rtcweb-security-arch-17 (work in progress), November 2018. 1015 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1016 A., Peterson, J., Sparks, R., Handley, M., and E. 1017 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1018 DOI 10.17487/RFC3261, June 2002, 1019 . 1021 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1022 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1023 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1024 . 1026 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1027 Session Initiation Protocol (SIP)", RFC 4353, 1028 DOI 10.17487/RFC4353, February 2006, 1029 . 1031 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1032 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1033 July 2006, . 1035 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1036 for Establishing a Secure Real-time Transport Protocol 1037 (SRTP) Security Context Using Datagram Transport Layer 1038 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1039 2010, . 1041 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1042 Security (DTLS) Extension to Establish Keys for the Secure 1043 Real-time Transport Protocol (SRTP)", RFC 5764, 1044 DOI 10.17487/RFC5764, May 2010, 1045 . 1047 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 1048 Transport Protocol (RTP) Header Extension for Client-to- 1049 Mixer Audio Level Indication", RFC 6464, 1050 DOI 10.17487/RFC6464, December 2011, 1051 . 1053 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1054 DOI 10.17487/RFC7667, November 2015, 1055 . 1057 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1058 "Authenticated Identity Management in the Session 1059 Initiation Protocol (SIP)", RFC 8224, 1060 DOI 10.17487/RFC8224, February 2018, 1061 . 1063 Authors' Addresses 1065 Paul E. Jones 1066 Cisco 1067 7025 Kit Creek Rd. 1068 Research Triangle Park, North Carolina 27709 1069 USA 1071 Phone: +1 919 476 2048 1072 Email: paulej@packetizer.com 1074 David Benham 1075 Independent 1077 Email: dabenham@gmail.com 1079 Christian Groves 1080 Independent 1081 Melbourne 1082 Australia 1084 Email: cngroves.std@gmail.com