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