idnits 2.17.1 draft-ietf-perc-private-media-framework-12.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 (June 5, 2019) is 1749 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-05 == 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: December 7, 2019 C. Groves 6 Independent 7 June 5, 2019 9 A Solution Framework for Private Media in Privacy Enhanced RTP 10 Conferencing (PERC) 11 draft-ietf-perc-private-media-framework-12 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 builds upon existing security mechanisms defined 20 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 December 7, 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 . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 7 62 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7 63 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7 65 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 10 69 4.4. HBH Keys and Per-hop Operations . . . . . . . . . . . . . 10 70 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 11 71 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 11 72 4.5.2. Key Exchange during a Conference . . . . . . . . . . 13 73 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 14 75 5.2. Certificate Fingerprints in Session Signaling . . . . . . 14 76 5.3. Conference Identification . . . . . . . . . . . . . . . . 15 77 6. PERC Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. Key Inventory and Management Considerations . . . . . . . 15 79 6.2. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 16 80 6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 17 81 6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 18 82 6.5. Summary of Key Types and Entity Possession . . . . . . . 18 83 7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 19 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 85 8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 20 86 8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 21 87 8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 21 88 8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 22 89 8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 22 90 8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 23 91 8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 23 92 8.3. Key Distributor Attacks . . . . . . . . . . . . . . . . . 23 93 8.4. Endpoint Attacks . . . . . . . . . . . . . . . . . . . . 24 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 98 11.2. Informative References . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 Switched conferencing is an increasingly popular model for multimedia 104 conferences with multiple participants using a combination of audio, 105 video, text, and other media types. With this model, real-time media 106 flows from conference participants are not mixed, transcoded, 107 transrated, recomposed, or otherwise manipulated by a Media 108 Distributor, as might be the case with a traditional media server or 109 multipoint control unit (MCU). Instead, media flows transmitted by 110 conference participants are simply forwarded by Media Distributors to 111 each of the other participants. Media Distributors often forward 112 only a subset of flows based on voice activity detection or other 113 criteria. In some instances, Media Distributors may make limited 114 modifications to RTP [RFC3550] headers, for example, but the actual 115 media content (e.g., voice or video data) is unaltered. 117 An advantage of switched conferencing is that Media Distributors can 118 be more easily deployed on general-purpose computing hardware, 119 including virtualized environments in private and public clouds. 120 Virtualized public cloud environments have been viewed as less secure 121 since resources are not always physically controlled by those who use 122 them. This document defines improved security so as to lower the 123 barrier to 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 This solution framework provides for enhanced privacy in RTP-based 138 conferencing environments while utilizing existing security 139 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 (or simply Endpoint): An RTP flow terminating entity 159 that has possession of E2E media encryption keys and terminates E2E 160 encryption. This may include embedded user conferencing equipment or 161 browsers on computers, media gateways, MCUs, media recording devices 162 and more that are in the trusted domain for a given deployment. In 163 the context of WebRTC [W3C.CR-webrtc-20180927], where control of a 164 session is divided between a JavaScript application and a browser, 165 the browser acts as the Trusted Endpoint for purposes of this 166 framework (just as it acts as the endpoint for DTLS-SRTP [RFC5764] in 167 one-to-one calls). 169 Media Distributor (MD): An RTP middlebox that forwards Endpoint media 170 content (e.g., voice or video data) unaltered, either a subset or all 171 of the flows at any given time, and is never allowed to have access 172 to E2E encryption keys. It operates according to the Selective 173 Forwarding Middlebox RTP topologies [RFC7667] per the constraints 174 defined by the PERC system, which includes, but is not limited to, 175 having no access to RTP media plaintext and having limits on what RTP 176 header field it can alter. The header fields that may be modified by 177 a Media Distributor are enumerated in Section 4 of the Double 178 cryptographic transform specification [I-D.ietf-perc-double] and 179 chosen with respect to utility and the security considerations 180 outlined in this document. 182 Key Distributor: An entity that is a logical function which 183 distributes keying material and related information to Trusted 184 Endpoints and Media Distributor(s), only that which is appropriate 185 for each. The Key Distributor might be co-resident with another 186 entity trusted with E2E keying material. 188 Conference: Two or more participants communicating via Trusted 189 Endpoints to exchange RTP flows through one or more Media 190 Distributor. 192 Call Processing: All Trusted Endpoints in the conference connect to 193 it by a call processing dialog, such as with the Focus defined in the 194 Framework for Conferencing with SIP [RFC4353]. 196 Third Party: Any entity that is not an Endpoint, Media Distributor, 197 Key Distributor or Call Processing entity as described in this 198 document. 200 3. PERC Entities and Trust Model 202 The following figure depicts the trust relationships, direct or 203 indirect, between entities described in the subsequent sub-sections. 204 Note that these entities may be co-located or further divided into 205 multiple, separate physical devices. 207 Please note that some entities classified as untrusted in the simple, 208 general deployment scenario used most commonly in this document might 209 be considered trusted in other deployments. This document does not 210 preclude such scenarios, but keeps the definitions and examples 211 focused by only using the simple, most general deployment 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 prevent 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 (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 (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 They Key Distributor needs to know which Endpoints and which Media 328 Distributors are authorized to participate in the conference. How 329 the Key Distributor obtains this information is outside the scope of 330 this document. However, Key Distributors MUST reject DTLS 331 associations with any unauthorized Endpoint or Media Distributor. 333 4. Framework for PERC 335 The purpose for this framework is to define a means through which 336 media privacy is ensured when communicating within a conferencing 337 environment consisting of one or more Media Distributors that only 338 switch, hence not terminate, media. It does not otherwise attempt to 339 hide the fact that a conference between Endpoints is taking place. 341 This framework reuses several specified RTP security technologies, 342 including Secure Real-time Transport Protocol (SRTP) [RFC3711], 343 Encrypted Key Transport (EKT) [I-D.ietf-perc-srtp-ekt-diet], and 344 DTLS-SRTP. 346 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 348 This solution framework focuses on the end-to-end privacy and 349 integrity of the participant's media by limiting access to only 350 trusted entities to the E2E key used for authenticated end-to-end 351 encryption. However, this framework does give a Media Distributor 352 access to RTP headers fields and header extensions, as well as the 353 ability to modify a certain subset of the header fields and to add or 354 change header extensions. Packets received by a Media Distributor or 355 an Endpoint are authenticated hop-by-hop. 357 To enable all of the above, this framework defines the use of two 358 security contexts and two associated encryption keys: an "inner" key 359 (an E2E key distinct for each transmitted media flow) for 360 authenticated encryption of RTP media between Endpoints and an 361 "outer" key (HBH key) known only to Media Distributor or the adjacent 362 Endpoint for the hop between an Endpoint and a Media Distributor or 363 peer Endpoint. An Endpoint will receive one or more E2E keys from 364 every other Endpoint in the conference that correspond to the media 365 flows transmitted by those other Endpoints, while HBH keys are 366 derived from the DTLS-SRTP association with the Key Distributor. Two 367 communicating Media Distributors use DTLS-SRTP associations directly 368 with each other to obtain the HBH keys they will use. See 369 Section 4.5 for more details on key exchange. 371 +-------------+ +-------------+ 372 | |################################| | 373 | Media |------------------------ *----->| Media | 374 | Distributor |<----------------------*-|------| Distributor | 375 | X |#####################*#|#|######| Y | 376 | | | | | | | 377 +-------------+ | | | +-------------+ 378 # ^ | # HBH Key (XY) -+ | | # ^ | # 379 # | | # E2E Key (B) ---+ | # | | # 380 # | | # E2E Key (A) -----+ # | | # 381 # | | # # | | # 382 # | | # # | | # 383 # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # 384 # | | # # | | # 385 # *--------- E2E Key (A) E2E Key (A) ---------* # 386 # | *------- E2E Key (B) E2E Key (B) -------* | # 387 # | | # # | | # 388 # | v # # | v # 389 +-------------+ +-------------+ 390 | Endpoint A | | Endpoint B | 391 +-------------+ +-------------+ 393 Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP 394 Packets 396 The Double transform [I-D.ietf-perc-double] enables Endpoints to 397 perform encryption using both the end-to-end and hop-by-hop contexts 398 while still preserving the same overall interface as other SRTP 399 transforms. The Media Distributor simply uses the corresponding 400 normal (single) AES-GCM transform, keyed with the appropriate HBH 401 keys. See Section 6.1 for a description of the keys used in PERC and 402 Section 7 for diagram of how encrypted RTP packets appear on the 403 wire. 405 RTCP is only encrypted hop-by-hop, not end-to-end. This framework 406 introduces no additional step for RTCP authenticated encryption, so 407 the procedures needed are specified in [RFC3711] and use the same 408 outer, hop-by-hop cryptographic context chosen in the Double 409 operation described above. For this reason, Endpoints MUST NOT send 410 confidential information via RTCP. 412 4.2. E2E Key Confidentiality 414 To ensure the confidentiality of E2E keys shared between Endpoints, 415 Endpoints use a common Key Encryption Key (KEK) that is known only by 416 the trusted entities in a conference. That KEK, defined in the EKT 417 specification [I-D.ietf-perc-srtp-ekt-diet] as the EKT Key, is used 418 to subsequently encrypt the SRTP master key used for E2E 419 authenticated encryption of media sent by a given Endpoint. Each 420 Endpoint in the conference creates an SRTP master key for E2E 421 authenticated encryption and keep track of the E2E keys received via 422 the Full EKT Tag for each distinct synchronization source (SSRC) in 423 the conference so that it can properly decrypt received media. An 424 Endpoint may change its E2E key at any time and advertise that new 425 key to the conference as specified in [I-D.ietf-perc-srtp-ekt-diet]. 427 4.3. E2E Keys and Endpoint Operations 429 Any given RTP media flow is identified by its SSRC, and an Endpoint 430 might send more than one at a time and change the mix of media flows 431 transmitted during the life of a conference. 433 Thus, an Endpoint MUST maintain a list of SSRCs from received RTP 434 flows and each SSRC's associated E2E key information. An Endpoint 435 MUST discard old E2E keys no later than when it leaves the conference 436 (see Section 4.5.2). 438 If the packet is to contain RTP header extensions, it should be noted 439 that those are only encrypted HBH per [I-D.ietf-perc-double]. For 440 this reason, Endpoints MUST NOT transmit confidential information via 441 RTP header extensions. 443 4.4. HBH Keys and Per-hop Operations 445 To ensure the integrity of transmitted media packets, it is REQUIRED 446 that every packet be authenticated hop-by-hop between an Endpoint and 447 a Media Distributor, as well between Media Distributors. The 448 authentication key used for hop-by-hop authentication is derived from 449 an SRTP master key shared only on the respective hop. Each HBH key 450 is distinct per hop and no two hops ever use the same SRTP master 451 key. 453 While Endpoints also perform HBH authentication, the ability of the 454 Endpoints to reconstruct the original RTP header also enables the 455 Endpoints to authenticate RTP packets E2E. This design yields 456 flexibility to the Media Distributor to change certain RTP header 457 values as packets are forwarded. Which values the Media Distributor 458 can change in the RTP header are defined in [I-D.ietf-perc-double]. 459 RTCP can only be encrypted hop-by-hop, giving the Media Distributor 460 the flexibility to forward RTCP content unchanged, transmit compound 461 RTCP packets or to initiate RTCP packets for reporting statistics or 462 conveying other information. Performing hop-by-hop authentication 463 for all RTP and RTCP packets also helps provide replay protection 464 (see Section 8). The use of the replay protection mechanism 465 specified in Section 3.3.2 of [RFC3711] is REQUIRED at each hop. 467 If there is a need to encrypt one or more RTP header extensions hop- 468 by-hop, the Endpoint derives an encryption key from the HBH SRTP 469 master key to encrypt header extensions as per [RFC6904]. This still 470 gives the Media Distributor visibility into header extensions, such 471 as the one used to determine audio level [RFC6464] of conference 472 participants. Note that when RTP header extensions are encrypted, 473 all hops need to decrypt and re-encrypt these encrypted header 474 extensions. Please refer to Sections 5.1 through 5.3 of 475 [I-D.ietf-perc-double] for procedures to perform RTP header extension 476 encryption and decryption. 478 4.5. Key Exchange 480 In brief, the keys used by any given Endpoints are determined in the 481 following way: 483 o The HBH keys that the Endpoint uses to send and receive SRTP media 484 are derived from a DTLS handshake that the Endpoint performs with 485 the Key Distributor (following normal DTLS-SRTP procedures). 487 o The E2E key that an Endpoint uses to send SRTP media can either be 488 set from the DTLS-SRTP association with the Key Distributor or 489 chosen by the Endpoint. It is then distributed to other Endpoints 490 in a Full EKT Tag, encrypted under an EKT Key provided to the 491 client by the Key Distributor within the DTLS channel they 492 negotiated. Note that an Endpoint MAY create a different E2E key 493 per media flow, where a media flow is identified by its SSRC 494 value. 496 o Each E2E key that an Endpoint uses to receive SRTP media is set by 497 receiving a Full EKT Tag from another Endpoint. 499 o The HBH keys used between two Media Distributors is derived from 500 DTLS-SRTP procedures employed directly between them. 502 4.5.1. Initial Key Exchange and Key Distributor 504 The Media Distributor maintains a tunnel with the Key Distributor 505 (e.g., using [I-D.ietf-perc-dtls-tunnel]), making it possible for the 506 Media Distributor to facilitate the establishment of a secure DTLS 507 association between each Endpoint and the Key Distributor as shown 508 the following figure. The DTLS association between Endpoints and the 509 Key Distributor enables each Endpoint to generate E2E and HBH keys 510 and receive the KEK. At the same time, the Key Distributor securely 511 provides the HBH key information to the Media Distributor. The key 512 information summarized here may include the SRTP master key, SRTP 513 master salt, and the negotiated cryptographic transform. 515 +-----------+ 516 KEK info | Key | HBH Key info to 517 to Endpoints |Distributor| Endpoints & Media Distributor 518 +-----------+ 519 # ^ ^ # 520 # | | #--- Tunnel 521 # | | # 522 +-----------+ +-----------+ +-----------+ 523 | Endpoint | DTLS | Media | DTLS | Endpoint | 524 | KEK |<------------|Distributor|------------>| KEK | 525 | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | 526 +-----------+ +-----------+ +-----------+ 528 Figure 3: Exchanging Key Information Between Entities 530 In addition to the secure tunnel between the Media Distributor and 531 the Key Distributor, there are two additional types of security 532 associations utilized as a part of the key exchange as discussed in 533 the following paragraphs. One is a DTLS-SRTP association between an 534 Endpoint and the Key Distributor (with packets passing through the 535 Media Distributor) and the other is a DTLS-SRTP association between 536 peer Media Distributors. 538 Endpoints establish a DTLS-SRTP association over the RTP session with 539 the Media Distributor and its media ports for the purposes of key 540 information exchange with the Key Distributor. The Media Distributor 541 does not terminate the DTLS signaling, but instead forwards DTLS 542 packets received from an Endpoint on to the Key Distributor (and vice 543 versa) via a tunnel established between Media Distributor and the Key 544 Distributor. 546 In establishing the DTLS association between Endpoints and the Key 547 Distributor, the Endpoint MUST act as the DTLS client and the Key 548 Distributor MUST act as the DTLS server. The KEK is conveyed by the 549 Key Distributor over the DTLS association to Endpoints via procedures 550 defined in EKT [I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message. 552 The Key Distributor MUST NOT establish DTLS-SRTP associations with 553 Endpoints without first authenticating the Media Distributor 554 tunneling the DTLS-SRTP packets from the Endpoint. 556 Note that following DTLS-SRTP procedures for the 557 [I-D.ietf-perc-double] cipher, the Endpoint generates both E2E and 558 HBH encryption keys and salt values. Endpoints MUST either use the 559 DTLS-SRTP generated E2E key for transmission or generate a fresh E2E 560 key. In either case, the generated SRTP master salt for E2E 561 encryption MUST be replaced with the salt value provided by the Key 562 Distributor via the EKTKey message. That is because every Endpoint 563 in the conference uses the same SRTP master salt. The Endpoint only 564 transmits the SRTP master key (not the salt) used for E2E encryption 565 to other Endpoints in RTP/RTCP packets per 566 [I-D.ietf-perc-srtp-ekt-diet]. 568 Media Distributors use DTLS-SRTP directly with a peer Media 569 Distributor to establish the HBH key for transmitting RTP and RTCP 570 packets to that peer Media Distributor. The Key Distributor does not 571 facilitate establishing a HBH key for use between Media Distributors. 573 4.5.2. Key Exchange during a Conference 575 Following the initial key information exchange with the Key 576 Distributor, an Endpoint is able to encrypt media end-to-end with an 577 E2E key, sending that E2E key to other Endpoints encrypted with the 578 KEK, and is able to encrypt and authenticate RTP packets using a HBH 579 key. The procedures defined do not allow the Media Distributor to 580 gain access to the KEK information, preventing it from gaining access 581 to any Endpoint's E2E key and subsequently decrypting media. 583 The KEK may need to change from time-to-time during the life of a 584 conference, such as when a new participant joins or leaves a 585 conference. Dictating if, when or how often a conference is to be 586 re-keyed is outside the scope of this document, but this framework 587 does accommodate re-keying during the life of a conference. 589 When a Key Distributor decides to re-key a conference, it transmits a 590 new EKTKey message containing the new EKT Key to each of the 591 conference participants. Upon receipt of the new EKT Key, the 592 Endpoint MUST create a new SRTP master key and prepare to send that 593 key inside a Full EKT Field using the new EKT Key as per Section 4.5 594 of [I-D.ietf-perc-srtp-ekt-diet]. In order to allow time for all 595 Endpoints in the conference to receive the new keys, the sender 596 should follow the recommendations in Section 4.7 of [I-D.ietf-perc- 597 srtp-ekt-diet]. On receiving a new EKT Key, Endpoints MUST be 598 prepared to decrypt EKT tags using the new key. The EKT SPI field is 599 used to differentiate between tags encrypted with the old and new 600 keys. 602 After re-keying, an Endpoint SHOULD retain prior SRTP master keys and 603 EKT Key for a period of time sufficient for the purpose of ensuring 604 it can decrypt late-arriving or out-of-order packets or packets sent 605 by other Endpoints that used the prior keys for a period of time 606 after re-keying began. An Endpoint MAY retain old keys until the end 607 of the conference. 609 Endpoints MAY follow the procedures in section 5.2 of [RFC5764] to 610 renegotiate HBH keys as desired. If new HBH keys are generated, the 611 new keys are also delivered to the Media Distributor following the 612 procedures defined in [I-D.ietf-perc-dtls-tunnel] as one possible 613 method. 615 Endpoints MAY change the E2E encryption key used at any time. An 616 Endpoint MUST generate a new E2E encryption key whenever it receives 617 a new EKT Key. After switching to a new key, the new key is conveyed 618 to other Endpoints in the conference in RTP/RTCP packets per 619 [I-D.ietf-perc-srtp-ekt-diet]. 621 5. Authentication 623 It is important to this solution framework that the entities can 624 validate the authenticity of other entities, especially the Key 625 Distributor and Endpoints. The details of this are outside the scope 626 of specification but a few possibilities are discussed in the 627 following sections. The critical requirements are that an Endpoint 628 can verify it is connected to the correct Key Distributor for the 629 conference and the Key Distributor can verify the Endpoint is the 630 correct Endpoint for the conference. 632 Two possible approaches to solve this are Identity Assertions and 633 Certificate Fingerprints. 635 5.1. Identity Assertions 637 WebRTC Identity assertion [I-D.ietf-rtcweb-security-arch] is used to 638 bind the identity of the user of the Endpoint to the fingerprint of 639 the DTLS-SRTP certificate used for the call. This certificate is 640 unique for a given call and a conference. This allows the Key 641 Distributor to ensure that only authorized users participate in the 642 conference. Similarly the Key Distributor can create a WebRTC 643 Identity assertion to bind the fingerprint of the unique certificate 644 used by the Key Distributor for this conference so that the Endpoint 645 can validate it is talking to the correct Key Distributor. Such a 646 setup requires an Identity Provider (Idp) trusted by the Endpoints 647 and the Key Distributor. 649 5.2. Certificate Fingerprints in Session Signaling 651 Entities managing session signaling are generally assumed to be 652 untrusted in the PERC framework. However, there are some deployment 653 scenarios where parts of the session signaling may be assumed 654 trustworthy for the purposes of exchanging, in a manner that can be 655 authenticated, the fingerprint of an entity's certificate. 657 As a concrete example, SIP [RFC3261] and Session Description Protocol 658 (SDP) [RFC4566] can be used to convey the fingerprint information per 659 [RFC5763]. An Endpoint's SIP User Agent would send an INVITE message 660 containing SDP for the media session along with the Endpoint's 661 certificate fingerprint, which can be signed using the procedures 662 described in [RFC8224] for the benefit of forwarding the message to 663 other entities by the Focus [RFC4353]. Other entities can verify the 664 fingerprints match the certificates found in the DTLS-SRTP 665 connections to find the identity of the far end of the DTLS-SRTP 666 connection and verify that is the authorized entity. 668 Ultimately, if using session signaling, an Endpoint's certificate 669 fingerprint would need to be securely mapped to a user and conveyed 670 to the Key Distributor so that it can check that that user is 671 authorized. Similarly, the Key Distributor's certificate fingerprint 672 can be conveyed to an Endpoint in a manner that can be authenticated 673 as being an authorized Key Distributor for this conference. 675 5.3. Conference Identification 677 The Key Distributor needs to know what Endpoints are being added to a 678 given conference. Thus, the Key Distributor and the Media 679 Distributor need to know Endpoint-to-conference mappings, which is 680 enabled by exchanging a conference-specific unique identifier defined 681 in [I-D.ietf-perc-dtls-tunnel]. How this unique identifier is 682 assigned is outside the scope of this document. 684 6. PERC Keys 686 This section describes the various keys employed by PERC. 688 6.1. Key Inventory and Management Considerations 690 This section summarizes the several different keys used in the PERC 691 framework, how they are generated, and what purpose they serve. 693 The keys are described in the order in which they would typically be 694 acquired. 696 The various keys used in PERC are shown in Figure 4 below. 698 +-----------+----------------------------------------------------+ 699 | Key | Description | 700 +-----------+----------------------------------------------------+ 701 | HBH Key | SRTP master key used to encrypt media hop-by-hop. | 702 +-----------+----------------------------------------------------+ 703 | KEK | Key shared by all Endpoints and used to encrypt | 704 | (EKT Key) | each Endpoint's E2E SRTP master key so receiving | 705 | | Endpoints can decrypt media. | 706 +-----------+----------------------------------------------------+ 707 | E2E Key | SRTP master key used to encrypt media end-to-end. | 708 +-----------+----------------------------------------------------+ 710 Figure 4: Key Inventory 712 While the number of key types is very small, it should be understood 713 that the actual number of distinct keys can be large as the 714 conference grows in size. 716 As an example, with 1,000 participants in a conference, there would 717 be at least 1,000 distinct SRTP master keys, all of which share the 718 same master salt. Each of those keys are passed through the KDF 719 defined in [RFC3711] to produce the actual encryption and 720 authentication keys. 722 Complicating key management is the fact that the KEK can change and, 723 when it does, the Endpoints generate new SRTP master keys that are 724 associated with a new EKT SPI. Endpoints might retain old keys for a 725 period of time to ensure they can properly decrypt late-arriving or 726 out-of-order packets, which means the number of keys held during that 727 period of time might substantially more. 729 A more detailed explanation of each of the keys follows. 731 6.2. DTLS-SRTP Exchange Yields HBH Keys 733 The first set of keys acquired are for hop-by-hop encryption and 734 decryption. Per the Double [I-D.ietf-perc-double] procedures, the 735 Endpoint performs DTLS-SRTP exchange with the Key Distributor and 736 receives a key that is, in fact, "double" the size that is needed. 737 The end-to-end part is the first half of the key, so the Endpoint 738 discards that information when generating its own key. The second 739 half of the key material is for hop-by-hop operations, so that half 740 of the key (corresponding to the least significant bits) is assigned 741 internally as the HBH key. 743 The Key Distributor informs the Media Distributor of the HBH key. 744 Specifically, the Key Distributor sends the least significant bits 745 corresponding to the half of the keying material determined through 746 DTLS-SRTP with the Endpoint to the Media Distributor. A salt value 747 is generated along with the HBH key. The salt is also longer than 748 needed for hop-by-hop operations, thus only the least significant 749 bits of the required length (half of the generated salt material) are 750 sent to the Media Distributor. One way to transmit this key and salt 751 information is via the tunnel protocol defined in 752 [I-D.ietf-perc-dtls-tunnel]. 754 No two Endpoints have the same HBH key, thus the Media Distributor 755 MUST keep track each distinct HBH key (and the corresponding salt) 756 and use it only for the specified hop. 758 The HBH key is also used for hop-by-hop encryption of RTCP. RTCP is 759 not end-to-end encrypted in PERC. 761 6.3. The Key Distributor Transmits the KEK (EKT Key) 763 Via the aforementioned DTLS-SRTP association, the Key Distributor 764 sends the Endpoint the KEK (EKT Key per 765 [I-D.ietf-perc-srtp-ekt-diet]). This key is known only to the Key 766 Distributor and Endpoints. This key is the most important to protect 767 since having knowledge of this key (and the SRTP master salt 768 transmitted as a part of the same message) allows an entity to 769 decrypt any media packet in the conference. 771 Note that the Key Distributor can send any number of EKT Keys to 772 Endpoints. This is used to re-key the entire conference. Each key 773 is identified by a "Security Parameter Index" (SPI) value. Endpoints 774 MUST expect that a conference might be re-keyed when a new 775 participant joins a conference or when a participant leaves a 776 conference in order to protect the confidentiality of the 777 conversation before and after such events. 779 The SRTP master salt to be used by the Endpoint is transmitted along 780 with the EKT Key. All Endpoints in the conference utilize the same 781 SRTP master salt that corresponds with a given EKT Key. 783 The Full EKT Tag in media packets is encrypted using a cipher 784 specified via the EKTKey message (e.g., AES Key Wrap with a 128-bit 785 key). This cipher is different than the cipher used to protect media 786 and is only used to encrypt the Endpoint's SRTP master key (and other 787 EKT Tag data as per [I-D.ietf-perc-srtp-ekt-diet]). 789 The Media Distributor is not given the KEK. 791 6.4. Endpoints fabricate an SRTP Master Key 793 As stated earlier, the E2E key determined via DTLS-SRTP MAY be 794 discarded in favor of a locally-generated E2E SRTP master key. While 795 the DTLS-SRTP-derived SRTP master key can be used initially, the 796 Endpoint might choose to change the SRTP master key periodically and 797 MUST change the SRTP master key as a result of the EKT key changing. 799 A locally-generated SRTP master key is used along with the master 800 salt transmitted to the Endpoint from the Key Distributor via the 801 EKTKey message to encrypt media end-to-end. 803 Since the Media Distributor is not involved in E2E functions, it does 804 not create this key nor have access to any Endpoint's E2E key. Note, 805 too, that even the Key Distributor is unaware of the locally- 806 generated E2E keys used by each Endpoint. 808 The Endpoint transmits its E2E key to other Endpoints in the 809 conference by periodically including it in SRTP packets in a Full EKT 810 Tag. When placed in the Full EKT Tag, it is encrypted using the EKT 811 Key provided by the Key Distributor. The master salt is not 812 transmitted, though, since all Endpoints receive the same master salt 813 via the EKTKey message from the Key Distributor. The recommended 814 frequency with which an Endpoint transmits its SRTP master key is 815 specified in [I-D.ietf-perc-srtp-ekt-diet]. 817 6.5. Summary of Key Types and Entity Possession 819 All Endpoints have knowledge of the KEK. 821 Every HBH key is distinct for a given Endpoint, thus Endpoint A and 822 Endpoint B do not have knowledge of the other's HBH key. Since HBH 823 keys are derived from a DTLS-SRTP association, there is at most one 824 HBH key per Endpoint, (The only exception is where the DTLS-SRTP 825 association might be rekeyed per Section 5.2 of [RFC5764] and a new 826 key is created to replace the former key.) 828 Each Endpoint generates its own E2E key (SRTP master key), thus there 829 is a distinct E2E key per endpoint. This key is transmitted 830 (encrypted) via the Full EKT Tag to other Endpoints. Endpoints that 831 receive media from a given transmitting Endpoint gain knowledge of 832 the transmitter's E2E key via the Full EKT Tag. 834 To summarize the various keys and which entity is in possession of a 835 given key, refer to Figure 5. 837 +----------------------+------------+-------+-------+------------+ 838 | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | 839 +----------------------+------------+-------+-------+------------+ 840 | KEK (EKT Key) | Yes | No | No | Yes | 841 +----------------------+------------+-------+-------+------------+ 842 | E2E Key (A and B) | Yes | No | No | Yes | 843 +----------------------+------------+-------+-------+------------+ 844 | HBH Key (A<=>MD X) | Yes | Yes | No | No | 845 +----------------------+------------+-------+-------+------------+ 846 | HBH Key (B<=>MD Y) | No | No | Yes | Yes | 847 +----------------------+------------+---------------+------------+ 848 | HBH Key (MD X<=>MD Y)| No | Yes | Yes | No | 849 +----------------------+------------+---------------+------------+ 851 Figure 5: Keys Types and Entity Possession 853 7. Encrypted Media Packet Format 855 Figure 6 presents a complete picture of what an encrypted media 856 packet per this framework looks like when transmitted over the wire. 857 The packet format shown is encrypted using the Double cryptographic 858 transform with an EKT Tag appended to the end. 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++ 863 |V=2|P|X| CC |M| PT | sequence number | IO 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 865 | timestamp | IO 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 867 | synchronization source (SSRC) identifier | IO 868 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO 869 | contributing source (CSRC) identifiers | IO 870 | .... | IO 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 872 | RTP extension (OPTIONAL) ... | |O 873 +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 874 O I | payload ... | IO 875 O I | +-------------------------------+ IO 876 O I | | RTP padding | RTP pad count | IO 877 O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 878 O | | E2E authentication tag | |O 879 O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O 880 O | | OHB ... | |O 881 +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ 882 | | | HBH authentication tag | || 883 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || 884 | | | EKT Tag ... | R || 885 | | +-+-+-+-+-+-+-+-+-+ | || 886 | | +- Neither encrypted nor authenticated; || 887 | | appended after Double is performed || 888 | | || 889 | | || 890 | +- E2E Encrypted Portion E2E Authenticated Portion ---+| 891 | | 892 +--- HBH Encrypted Portion HBH Authenticated Portion ----+ 894 I = Inner (E2E) encryption / authentication 895 O = Outer (HBH) encryption / authentication 897 Figure 6: Encrypted Media Packet Format 899 8. Security Considerations 901 8.1. Third Party Attacks 903 Third party attacks are attacks attempted by an adversary that is not 904 supposed to have access to keying material or is otherwise not an 905 authorized participant in the conference. 907 On-path attacks are mitigated by hop-by-hop integrity protection and 908 encryption. The integrity protection mitigates packet modification 909 and encryption makes selective blocking of packets harder, but not 910 impossible. 912 Off-path attackers could try connecting to different PERC entities to 913 send specifically crafted packets with an aim of forcing the receiver 914 to forward or render bogus media packets. Endpoints and Media 915 Distributors mitigate such an attack by performing hop-by-hop 916 authentication and discarding packets that fail authentication. 918 Another attack vector is a third party claiming to be a Media 919 Distributor, fooling Endpoints into sending packets to the false 920 Media Distributor instead of the correct one. The deceived sending 921 Endpoints could incorrectly assume their packets have been delivered 922 to Endpoints when they in fact have not. While this attack is 923 possible, the result is a simple denial of service with no leakage of 924 confidential information, since the false Media Distributor would not 925 have access to either HBH or E2E encryption keys. 927 A third party could cause a denial-of-service by transmitting many 928 bogus or replayed packets toward receiving devices that ultimately 929 degrade conference or device performance. Therefore, implementations 930 might wish to devise mechanisms to safeguard against such 931 illegitimate packets, such as utilizing rate-limiting or performing 932 basic sanity-checks on packets (e.g., looking at packet length or 933 expected sequence number ranges) before performing more expensive 934 decryption operations. 936 Use of mutual DTLS authentication (as required by DTLS-SRTP) also 937 helps to prevent a denial-of-service attack by preventing a false 938 Endpoint or false Media Distributor from successfully participating 939 as a perceived valid media sender that could otherwise carry out an 940 on-path attack. When mutual authentication fails, a receiving 941 Endpoint would know that it could safely discard media packets 942 received from the Endpoint without inspection. 944 8.2. Media Distributor Attacks 946 A malicious or compromised Media Distributor can attack the session 947 in a number of possible ways. 949 8.2.1. Denial of service 951 A simple form of attack is discarding received packets that should be 952 forwarded. This solution framework does not introduce any mitigation 953 for Media Distributors that fail to forward media packets. 955 Another form of attack is modifying received packets before 956 forwarding. With this solution framework, any modification of the 957 end-to-end authenticated data results in the receiving Endpoint 958 getting an integrity failure when performing authentication on the 959 received packet. 961 The Media Distributor can also attempt to perform resource 962 consumption attacks on the receiving Endpoint. One such attack would 963 be to insert random SSRC/CSRC values in any RTP packet along with a 964 Full EKT Tag. Since such a message would trigger the receiver to 965 form a new cryptographic context, the Media Distributor can attempt 966 to consume the receiving Endpoint's resources. While E2E 967 authentication would fail and the cryptographic context would be 968 destroyed, the key derivation operation would nonetheless consume 969 some computational resources. While resource consumption attacks 970 cannot be mitigated entirely, rate-limiting packets might help reduce 971 the impact of such attacks. 973 8.2.2. Replay Attack 975 A replay attack is when an already received packet from a previous 976 point in the RTP stream is replayed as new packet. This could, for 977 example, allow a Media Distributor to transmit a sequence of packets 978 identified as a user saying "yes", instead of the "no" the user 979 actually said. 981 A replay attack is mitigated by the requirement to implement replay 982 protection as described in Section 3.3.2 of [RFC3711]. End-to-end 983 replay protection MUST be provided for the duration of the 984 conference. 986 8.2.3. Delayed Playout Attack 988 A delayed playout attack is one where media is received and held by a 989 Media Distributor and then forwarded to Endpoints at a later point in 990 time. 992 This attack is possible even if E2E replay protection is in place. 993 Because the Media Distributor is allowed to select a subset of 994 streams and not forward the rest to a receiver, such as in forwarding 995 only the most active speakers, the receiver has to accept gaps in the 996 E2E packet sequence. The issue with this is that a Media Distributor 997 can select to not deliver a particular stream for a while. 999 While the Media Distributor can purposely stop forwarding media 1000 flows, it can also select an arbitrary starting point to resume 1001 forwarding those media flow, perhaps forwarding old packets rather 1002 than current packets. As a consequence, what the media source sent 1003 can be substantially delayed at the receiver with the receiver 1004 believing that newly arriving packets are delayed only by transport 1005 delay when the packets may actually be minutes or hours old. 1007 While this attack cannot be eliminated entirely, its effectiveness 1008 can be reduced by re-keying the conference periodically since 1009 significantly-delayed media encrypted with expired keys would not be 1010 decrypted by Endpoints. 1012 8.2.4. Splicing Attack 1014 A splicing attack is an attack where a Media Distributor receiving 1015 multiple media sources splices one media stream into the other. If 1016 the Media Distributor were able to change the SSRC without the 1017 receiver having any method for verifying the original source ID, then 1018 the Media Distributor could first deliver stream A and then later 1019 forward stream B under the same SSRC as stream A was previously 1020 using. By including the SSRC in the integrity check for each packet, 1021 both HBH and E2E, PERC prevents splicing attacks. 1023 8.2.5. RTCP Attacks 1025 PERC does not provide end-to-end protection of RTCP messages. This 1026 allows a compromised Media Distributor to impact any message that 1027 might be transmitted via RTCP, including media statistics, picture 1028 requests, or loss indication. It is also possible for a compromised 1029 Media Distributor to forge requests, such as requests to the Endpoint 1030 to send a new picture. Such requests can consume significant 1031 bandwidth and impair conference performance. 1033 8.3. Key Distributor Attacks 1035 As stated in Section 3.2.2, the Key Distributor needs to be secured 1036 since exploiting the Key Server can allow an adversary to gain access 1037 to the keying material for one or more conferences. Having access to 1038 that keying material would then allow the adversary to decrypt media 1039 sent from any Endpoint in the conference. 1041 As a first line of defense, the Key Distributor authenticates every 1042 security association, both associations with Endpoints and Media 1043 Distributors. The Key Distributor knows which entities are 1044 authorized to have access to which keys and inspection of 1045 certificates will substantially reduce the risk of providing keys to 1046 an adversary. 1048 Both physical and network access to the Key Distributor should be 1049 severely restricted. This may be more difficult to achieve when the 1050 Key Distributor is embedded within and Endpoint, for example. 1052 Nonetheless, consideration should be given to shielding the Key 1053 Distributor from unauthorized access or any access that is not 1054 strictly necessary for the support of an ongoing conference. 1056 Consideration should be given to whether access to the keying 1057 material will be needed beyond the conclusion of a conference. If 1058 not needed, the Key Distributor's policy should be to destroy the 1059 keying material once the conference concludes or when keying material 1060 changes during the course of the conference. If keying material is 1061 needed beyond the lifetime of the conference, further consideration 1062 should be given to protecting keying material from future exposure. 1063 While it might be obvious, it is worth stating to avoid any doubt 1064 that if an adversary were to record the media packets transmitted 1065 during a conference and then gain unauthorized access to the keying 1066 material left unsecured on the Key Distributor even years later, the 1067 adversary could decrypt the content every packet transmitted during 1068 the conference. 1070 8.4. Endpoint Attacks 1072 A Trusted Endpoint is so named because conference confidentiality 1073 relies heavily on the security and integrity of the Endpoint. If an 1074 adversary successfully exploits a vulnerability in an Endpoint, it 1075 might be possible for the adversary to obtain all of the keying 1076 material used in the conference. With that keying material, an 1077 adversary could decrypt any of the media flows received from any 1078 other Endpoint, either in real-time or at a later point in time 1079 (assuming the adversary makes a copy of the media packets). 1081 Additionally, if an adversary successfully exploits an Endpoint, the 1082 adversary could inject media into the conference. One way an 1083 adversary could do that is by manipulating the RTP or SRTP software 1084 to transmit whatever media the adversary wishes to send. This could 1085 involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value 1086 of an existing endpoint. This is made possible since all conference 1087 participants share the same KEK. Only a single SRTP cipher suite 1088 defined provides source authentication properties that allow an 1089 endpoint to cryptographically assert that it sent a particular E2E 1090 protected packet (namely, TESLA [RFC4383]), and its usage is 1091 presently not defined for PERC. The suite defined in PERC only 1092 allows an Endpoint to determine that whoever sent a packet had 1093 received the KEK. 1095 However, attacks on the endpoint are not limited to the PERC-specific 1096 software within the Endpoint. An attacker could inject media or 1097 record media by manipulating the software that sits between the PERC- 1098 enabled application and the hardware microphone of video camera, for 1099 example. Likewise, an attacker could potentially access confidential 1100 media by accessing memory, cache, disk storage, etc. if the endpoint 1101 is no secured. 1103 9. IANA Considerations 1105 There are no IANA considerations for this document. 1107 10. Acknowledgments 1109 The authors would like to thank Mo Zanaty, Christian Oien, and 1110 Richard Barnes for invaluable input on this document. Also, we would 1111 like to acknowledge Nermeen Ismail for serving on the initial 1112 versions of this document as a co-author. We would also like to 1113 acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for 1114 providing some of the text in the document, including much of the 1115 original text in the security considerations section. 1117 11. References 1119 11.1. Normative References 1121 [I-D.ietf-perc-double] 1122 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 1123 Double Encryption Procedures", draft-ietf-perc-double-10 1124 (work in progress), October 2018. 1126 [I-D.ietf-perc-srtp-ekt-diet] 1127 Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. 1128 Andreasen, "Encrypted Key Transport for DTLS and Secure 1129 RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress), 1130 October 2018. 1132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1133 Requirement Levels", BCP 14, RFC 2119, 1134 DOI 10.17487/RFC2119, March 1997, 1135 . 1137 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1138 Jacobson, "RTP: A Transport Protocol for Real-Time 1139 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1140 July 2003, . 1142 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1143 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1144 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1145 . 1147 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1148 Real-time Transport Protocol (SRTP)", RFC 6904, 1149 DOI 10.17487/RFC6904, April 2013, 1150 . 1152 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1153 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1154 May 2017, . 1156 11.2. Informative References 1158 [I-D.ietf-perc-dtls-tunnel] 1159 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 1160 between a Media Distributor and Key Distributor to 1161 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05 1162 (work in progress), April 2019. 1164 [I-D.ietf-rtcweb-security-arch] 1165 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1166 rtcweb-security-arch-18 (work in progress), February 2019. 1168 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1169 A., Peterson, J., Sparks, R., Handley, M., and E. 1170 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1171 DOI 10.17487/RFC3261, June 2002, 1172 . 1174 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1175 Session Initiation Protocol (SIP)", RFC 4353, 1176 DOI 10.17487/RFC4353, February 2006, 1177 . 1179 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1180 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1181 Real-time Transport Protocol (SRTP)", RFC 4383, 1182 DOI 10.17487/RFC4383, February 2006, 1183 . 1185 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1186 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1187 July 2006, . 1189 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1190 for Establishing a Secure Real-time Transport Protocol 1191 (SRTP) Security Context Using Datagram Transport Layer 1192 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1193 2010, . 1195 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1196 Security (DTLS) Extension to Establish Keys for the Secure 1197 Real-time Transport Protocol (SRTP)", RFC 5764, 1198 DOI 10.17487/RFC5764, May 2010, 1199 . 1201 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 1202 Transport Protocol (RTP) Header Extension for Client-to- 1203 Mixer Audio Level Indication", RFC 6464, 1204 DOI 10.17487/RFC6464, December 2011, 1205 . 1207 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1208 DOI 10.17487/RFC7667, November 2015, 1209 . 1211 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1212 "Authenticated Identity Management in the Session 1213 Initiation Protocol (SIP)", RFC 8224, 1214 DOI 10.17487/RFC8224, February 2018, 1215 . 1217 [W3C.CR-webrtc-20180927] 1218 Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., 1219 Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: 1220 Real-time Communication Between Browsers", World Wide Web 1221 Consortium CR CR-webrtc-20180927, September 2018, 1222 . 1224 Authors' Addresses 1226 Paul E. Jones 1227 Cisco 1228 7025 Kit Creek Rd. 1229 Research Triangle Park, North Carolina 27709 1230 USA 1232 Phone: +1 919 476 2048 1233 Email: paulej@packetizer.com 1235 David Benham 1236 Independent 1238 Email: dabenham@gmail.com 1239 Christian Groves 1240 Independent 1241 Melbourne 1242 Australia 1244 Email: cngroves.std@gmail.com