idnits 2.17.1 draft-ietf-perc-private-media-framework-02.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 (October 31, 2016) is 2705 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-01 == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-01 == Outdated reference: A later version (-04) exists of draft-jones-perc-dtls-tunnel-03 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones 3 Internet-Draft D. Benham 4 Intended status: Standards Track Cisco 5 Expires: May 4, 2017 C. Groves 6 Huawei 7 October 31, 2016 9 A Solution Framework for Private Media in Privacy Enhanced RTP 10 Conferencing 11 draft-ietf-perc-private-media-framework-02 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 distribution devices are not trusted with the end-to-end media 19 encryption keys. The solution aims to build upon existing security 20 mechanisms 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 http://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 May 4, 2017. 39 Copyright Notice 41 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 4 59 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 5 61 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6 62 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 6 63 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7 65 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 7 67 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 8 68 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9 69 4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 9 70 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 10 72 4.5.2. Key Exchange during a Conference . . . . . . . . . . 11 73 5. Entity Trust . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 12 75 5.2. Certificate Fingerprints in Session Signaling . . . . . . 12 76 5.3. Conferences Identification . . . . . . . . . . . . . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 13 79 6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 14 80 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 14 81 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 15 82 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 15 83 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 15 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 9.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 Switched conferencing is an increasingly popular model for multimedia 94 conferences with multiple participants using a combination of audio, 95 video, text, and other media types. With this model, real-time media 96 flows from conference participants are not mixed, transcoded, 97 transrated, recomposed, or otherwise manipulated by a Media 98 Distributor, as might be the case with a traditional media server or 99 multipoint control unit (MCU). Instead, media flows transmitted by 100 conference participants are simply forwarded by the Media Distributor 101 to each of the other participants, often forwarding only a subset of 102 flows based on voice activity detection or other criteria. In some 103 instances, the Media Distributors may make limited modifications to 104 RTP [RFC3550] headers, for example, but the actual media content 105 (e.g., voice or video data) is unaltered. 107 An advantage of switched conferencing is that Media Distributors can 108 be more easily deployed on general-purpose computing hardware, 109 including virtualized environments in private and public clouds. 110 Deploying conference resources in a public cloud environment might 111 introduce a higher security risk. Whereas traditional conference 112 resources were usually deployed in private networks that were 113 protected, cloud-based conference resources might be viewed as less 114 secure since they are not always physically controlled by those who 115 use them. Additionally, there are usually several ports open to the 116 public in cloud deployments, such as for remote administration, and 117 so on. 119 This document defines a solution framework wherein media privacy is 120 ensured by making it impossible for a media distribution device to 121 gain access to keys needed to decrypt or authenticate the actual 122 media content sent between conference participants. At the same 123 time, the framework allows for the Media Distributors to modify 124 certain RTP headers; add, remove, encrypt, or decrypt RTP header 125 extensions; and encrypt and decrypt RTCP packets. The framework also 126 prevents replay attacks by authenticating each packet transmitted 127 between a given participant and the media distribution device using a 128 unique key per endpoint that is independent from the key for media 129 encryption and authentication. 131 A goal of this document is to define a framework for enhanced privacy 132 in RTP-based conferencing environments while utilizing existing 133 security procedures defined for RTP with minimal enhancements. 135 2. Conventions Used in This Document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119] when they 140 appear in ALL CAPS. These words may also appear in this document in 141 lower case as plain English words, absent their normative meanings. 143 Additionally, this solution framework uses the following conventions, 144 terms and acronyms: 146 End-to-End (E2E): Communications from one endpoint through one or 147 more Media Distribution Devices to the endpoint at the other end. 149 Hop-by-Hop (HBH): Communications between an endpoint and a Media 150 Distribution Device or between Media Distribution Devices. 152 Endpoint: An RTP flow terminating entity that has possession of E2E 153 media encryption keys and terminates E2E encryption. This may 154 include embedded user conferencing equipment or browsers on 155 computers, media gateways, MCUs, media recording device and more that 156 are in the trusted domain for a given deployment. 158 Media Distributor (MD): An RTP middlebox that is not allowed to to 159 have access to E2E encryption keys. It operates according to the 160 Selective Forwarding Middlebox RTP topologies 161 [I-D.ietf-avtcore-rtp-topologies-update] per the constraints defined 162 by the PERC system, which includes, but not limited to, having no 163 access to RTP media unencrypted and having limits on what RTP header 164 field it can alter. 166 Key Distributor: An entity that is a logical function which passes 167 keying material and related information to endpoints and Media 168 Distributor(s) that is appropriate for each. The Key Distributor 169 might be co-resident with another entity trusted with E2E keying 170 material. 172 Conference: Two or more participants communicating via trusted 173 endpoints to exchange RTP flows through one or more Media 174 Distributor. 176 Third Party: Any entity that is not an Endpoint, Media Distributor, 177 Key Distributor or Call Processing entity as described in this 178 document. 180 3. PERC Entities and Trust Model 182 The following figure depicts the trust relationships, direct or 183 indirect, between entities described in the subsequent sub-sections. 184 Note that these entities may be co-located or further divided into 185 multiple, separate physical devices. 187 Please note that some entities classified as untrusted in the simple, 188 general deployment scenario used most commonly in this document might 189 be considered trusted in other deployments. This document does not 190 preclude such scenarios, but will keep the definitions and examples 191 focused by only using the the simple, most general deployment 192 scenario. 194 | 195 +----------+ | +-----------------+ 196 | Endpoint | | | Call Processing | 197 +----------+ | +-----------------+ 198 | 199 | 200 +----------------+ | +--------------------+ 201 | Key Distributor| | | Media Distributor | 202 +----------------+ | +--------------------+ 203 | 204 Trusted | Untrusted 205 Entities | Entities 206 | 208 Figure 1: Trusted and Untrusted Entities in PERC 210 3.1. Untrusted Entities 212 The architecture described in this framework document enables 213 conferencing infrastructure to be hosted in domains, such as in a 214 cloud conferencing provider's facilities, where the trustworthiness 215 is below the level needed to assume the privacy of participant's 216 media will not be compromised. The conferencing infrastructure in 217 such a domain is still trusted with reliably connecting the 218 participants together in a conference, but not trusted with keying 219 material needed to decrypt any of the participant's media. Entities 220 in such lower trustworthiness domains will simply be referred to as 221 untrusted entities from this point forward. This does not mean that 222 they are completely untrusted as they may be trusted with most non- 223 media related aspects of hosting a conference. 225 3.1.1. Media Distributor 227 A Media Distributor forwards RTP flows between endpoints in the 228 conference while performing per-hop authentication of each RTP 229 packet. The Media Distributor may need access to one or more RTP 230 headers or header extensions, potentially adding or modifying a 231 certain subset. The Media Distributor will also relay secured 232 messaging between the endpoints and the Key Distributor and will 233 acquire per-hop key information from the Key Distributor. The actual 234 media content MUST NOT not be decryptable by a Media Distributor, so 235 it is untrusted to have access to the E2E media encryption keys, 236 which this framework's key exchange mechanisms will prevent. 238 An endpoint's ability to join a conference hosted by a Media 239 Distributor MUST NOT alone be interpreted as being authorized to have 240 access to the E2E media encryption keys, as the Media Distributor 241 does not have the ability to determine whether an endpoint is 242 authorized. 244 A Media Distributor MUST perform its role in properly forwarding 245 media packets while taking measures to mitigate the adverse effects 246 of denial of service attacks (refer to Section 6), etc, to a level 247 equal to or better than traditional conferencing (i.e. pre-PERC) 248 deployments. 250 A Media Distributor or associated conferencing infrastructure may 251 also initiate or terminate various conference control related 252 messaging, which is outside the scope of this framework document. 254 3.1.2. Call Processing 256 The call processing function is untrusted in the simple, general 257 deployment scenario. When a physical subset of the call processing 258 function resides in facilities outside the trusted domain, it should 259 not be trusted to have access to E2E key information. 261 The call processing function may include the processing of call 262 signaling messages, as well as the signing of those messages. It may 263 also authenticate the endpoints for the purpose of call signaling and 264 subsequently joining of a conference hosted through one or more Media 265 Distributors. Call processing may optionally ensure the privacy of 266 call signaling messages between itself, the endpoint, and other 267 entities. 269 In any deployment scenario where the call processing function is 270 considered trusted, the call processing function MUST ensure the 271 integrity of received messages before forwarding to other entities. 273 3.2. Trusted Entities 275 From the PERC model system perspective, entities considered trusted 276 (refer to Figure 1) can be in possession of the E2E media encryption 277 key(s) for one or more conferences. 279 3.2.1. Endpoint 281 An endpoint is considered trusted and will have access to E2E key 282 information. While it is possible for an endpoint to be compromised, 283 subsequently performing in undesired ways, defining endpoint 284 resistance to compromise is outside the scope of this document. 285 Endpoints will take measures to mitigate the adverse effects of 286 denial of service attacks (refer to Section 6) from other entities, 287 including from other endpoints, to a level equal to or better than 288 traditional conference (i.e., pre-PERC) deployments. 290 3.2.2. Key Distributor 292 The Key Distributor, which may be collocated with an endpoint or 293 exist standalone, is responsible for providing key information to 294 endpoints for both end-to-end and hop-by-hop security and for 295 providing key information to Media Distributors for the hop-by-hop 296 security. 298 Interaction between the Key Distributor and the call processing 299 function is necessary to for proper conference-to-endpoint mappings. 300 This is described in Section 5.3. 302 The Key Distributor needs to be secured and managed in a way to 303 prevent exploitation by an adversary, as any kind of compromise of 304 the Key Distributor puts the security of the conference at risk. 306 4. Framework for PERC 308 The purpose for this framework is to define a means through which 309 media privacy can be ensured when communicating within a conferencing 310 environment consisting of one or more Media Distributors that only 311 switch, hence not terminate, media. It does not otherwise attempt to 312 hide the fact that a conference between endpoints is taking place. 314 This framework reuses several specified RTP security technologies, 315 including SRTP [RFC3711], PERC EKT [I-D.ietf-perc-srtp-ekt-diet], and 316 DTLS-SRTP [RFC5764]. 318 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 320 This solution framework focuses on the end-to-end privacy and 321 integrity of the participant's media by limiting access of the end- 322 to-end key information to trusted entities. However, this framework 323 does give a Media Distributor access to RTP headers and all or most 324 header extensions, as well as the ability to modify a certain subset 325 of those headers and to add header extensions. Packets received by a 326 Media Distributor or an endpoint are authenticated hop-by-hop. 328 To enable all of the above, this framework defines the use of two 329 security contexts and two associated encryption keys; an "inner" key 330 (E2E Key(i); i={a given endpoint}) for authenticated encryption of 331 RTP media between endpoints and an "outer" key (HBH Key(j); j={a 332 given hop}) for the hop between an endpoint and a Media Distributor 333 or between Media Distributor. Reference the following figure. 335 +-------------+ +-------------+ 336 | |################################| | 337 | Media |------------------------------->| Media | 338 | Distributor |<-------------------------------| Distributor | 339 | X |################################| Y | 340 | | HBH Key (XY) | | 341 +-------------+ +-------------+ 342 # ^ | # # ^ | # 343 # | | # HBH HBH # | | # 344 # | | # <== Key(AX) Key(YB) ==> # | | # 345 # | | # # | | # 346 # |<+--#---- E2E Key (A) E2E Key (B) ---#->| | # 347 # | | # # | | # 348 # | v # # | v # 349 +-------------+ +-------------+ 350 | Endpoint A | | Endpoint B | 351 +-------------+ +-------------+ 353 E2E and HBH Keys Used for Authenticated Encryption 355 The PERC Double draft specification [I-D.ietf-perc-double] uses 356 standard SRTP keying material and recommended cryptographic 357 transform(s) to first form the inner, end-to-end SRTP cryptographic 358 context. That end-to-end SRTP cryptographic context MAY be used to 359 encrypt some RTP header extensions along with RTP media content. The 360 output of this is treated like an RTP packet and encrypted again 361 using the outer hop-by-hop cryptographic context. The endpoint 362 executes the entire Double operation while the Media Distributor just 363 performs the outer, hop-by-hop operation. 365 RTCP can only be encrypted hop-by-hop, not end-to-end. This 366 framework introduces no additional step for RTCP authenticated 367 encryption, so the procedures needed are specified in [RFC3711] and 368 use the same outer, hop-by-hop cryptographic context chosen in the 369 Double operation described above. 371 4.2. E2E Key Confidentiality 373 To ensure the confidentiality of E2E keys shared between endpoints, 374 endpoints will make use of a common Key Encryption Key (KEK) that is 375 known only by the trusted entities in a conference. That KEK, 376 defined in the PERC EKT [I-D.ietf-perc-srtp-ekt-diet] as the EKTKey, 377 will be used to subsequently encrypt SRTP master keys used for E2E 378 authenticated encryption (E2E Key(i); i={a given endpoint}) of media 379 sent by a given endpoint. 381 +---------------------+------------+-------+-------+------------+ 382 | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | 383 +---------------------+------------+-------+-------+------------+ 384 | KEK | Yes | No | No | Yes | 385 +---------------------+------------+-------+-------+------------+ 386 | E2E Key (i) | Yes | No | No | Yes | 387 +---------------------+------------+-------+-------+------------+ 388 | HBH Key (A<=>MD X) | Yes | Yes | No | No | 389 +---------------------+------------+-------+-------+------------+ 390 | HBH Key (B<=>MD Y) | No | No | Yes | Yes | 391 +---------------------+------------+---------------+------------+ 393 Figure 2: Keys per Entity 395 4.3. E2E Keys and Endpoint Operations 397 Any given RTP media flow can be identified by its SSRC, and endpoints 398 might send more than one at a time and change the mix of media flows 399 transmitted during the life of a conference. 401 Thus, endpoints MUST maintain a list of SSRCs from received RTP flows 402 and each SSRC's associated E2E Key(i) information. Following a 403 change of the KEK (i.e., EKTKey), prior E2E Key(i) information SHOULD 404 be retained for a period long enough to ensure that late-arriving or 405 out-of-order packets from other endpoints can be successfully 406 decrypted. The endpoint MUST discard the E2E Key(i) and KEK 407 information no later than when it leaves the conference. 409 If there is a need to encrypt one or more RTP header extensions end- 410 to-end, an encryption key is derived from the end-to-end SRTP master 411 key to encrypt header extensions as per [RFC6904]. The Media 412 Distributor will not be able use the information contained in those 413 header extensions encrypted with E2E keys. 415 4.4. HBH Keys and Hop Operations 417 To ensure the integrity of transmitted media packets, this framework 418 requires that every packet be authenticated hop-by-hop (HBH) between 419 an endpoint and a Media Distributor, as well between Media 420 Distributors. The authentication key used for hop-by-hop 421 authentication is derived from an SRTP master key shared only on the 422 respective hop (HBH Key(j); j={a given hop}). Each HBH Key(j) is 423 distinct per hop and no two hops ever intentionally use the same SRTP 424 master key. 426 Using hop-by-hop authentication gives the Media Distributor the 427 ability to change certain RTP header values. Which values the Media 428 Distributor can change in the RTP header are defined in 430 [I-D.ietf-perc-double]. RTCP can only be encrypted, giving the Media 431 Distributor the flexibility to forward RTCP content unchanged, 432 transmit compound RTCP packets or to initiate RTCP packets for 433 reporting statistics or conveying other information. Performing hop- 434 by-hop authentication for all RTP and RTCP packets also helps provide 435 replay protection (see Section 6). 437 If there is a need to encrypt one or more RTP header extensions hop- 438 by-hop, an encryption key is derived from the hop-by-hop SRTP master 439 key to encrypt header extensions as per [RFC6904]. This will still 440 give the Media Distributor visibility into header extensions, such as 441 the one used to determine audio level [RFC6464] of conference 442 participants. Note that when RTP header extensions are encrypted, 443 all hops - in the untrusted domain at least - will need to decrypt 444 and re-encrypt these encrypted header extensions. 446 4.5. Key Exchange 448 To facilitate key exchange required to establish or generate an E2E 449 key and a HBH key for an endpoint and the same HBH key for the Media 450 Distributor, this framework utilizes a DTLS-SRTP [RFC5764] 451 association between an endpoint and the Key Distributor. To 452 establish this association, an endpoint will send DTLS-SRTP messages 453 to the Media Distributor which will then forward them to the Key 454 Distributor as defined in [I-D.jones-perc-dtls-tunnel]. The Key 455 Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key 456 Distributor over the DTLS association to endpoints via procedures 457 defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet]. 459 Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media 460 Distributor to establish HBH keys for transmitting RTP and RTCP 461 packets to that peer Media Distributor. The Key Distributor does not 462 facilitate establishing HBH keys for use between Media Distributors. 464 4.5.1. Initial Key Exchange and Key Distributor 466 The procedures defined in DTLS Tunnel for PERC 467 [I-D.jones-perc-dtls-tunnel] establish one or more TLS tunnels 468 between the Media Distributor and Key Distributor, making it is 469 possible for the Media Distributor to facilitate the establishment of 470 a secure DTLS association between each endpoint and the Key 471 Distributor as shown the following figure. The DTLS association 472 between endpoints and the Key Distributor will enable each endpoint 473 to receive E2E key information, Key Encryption Key (KEK) information 474 (i.e., EKTKey), and HBH key information. At the same time, the Key 475 Distributor can securely provide the HBH key information to the Media 476 Distributor. The key information summarized here may include the 477 SRTP master key, SRTP master salt, and the negotiated cryptographic 478 transform. 480 +-----------+ 481 KEK info | Key | HBH Key info to 482 to Endpoints |Distributor| Endpoints & Media Distributor 483 +-----------+ 484 # ^ ^ # 485 # | | #-TLS Tunnel 486 # | | # 487 +-----------+ +-----------+ +-----------+ 488 | Endpoint | DTLS | Media | DTLS | Endpoint | 489 | KEK |<------------|Distributor|------------>| KEK | 490 | HBH Key(j)| to Key Dist | HBH Keys | to Key Dist | HBH Key(j)| 491 +-----------+ +-----------+ +-----------+ 493 Figure 3: Exchanging Key Information Between Entities 495 Endpoints will establish a DTLS-SRTP association over the RTP 496 session's media ports for the purposes of key information exchange 497 with the Key Distributor. The Media Distributor will not terminate 498 the DTLS signaling, but will instead forward DTLS packets received 499 from an endpoint on to the Key Distributor (and vice versa) via a 500 tunnel established between Media Distributor and the Key Distributor. 501 This tunnel is used to encapsulate the DTLS-SRTP signaling between 502 the Key Distributor and endpoints will also be used to convey HBH key 503 information from the Key Distributor to the Media Distributor, so no 504 additional protocol or interface is required. 506 4.5.2. Key Exchange during a Conference 508 Following the initial key information exchange with the Key 509 Distributor, endpoints will be able to encrypt media end-to-end with 510 their E2E Key(i), sending that E2E Key(i) to other endpoints 511 encrypted with KEK, and will be able to encrypt and authenticate RTP 512 packets using local HBH Key(j). The procedures defined do not allow 513 the Media Distributor to gain access to the KEK information, 514 preventing it from gaining access to any endpoint's E2E key and 515 subsequently decrypting media. 517 The KEK (i.e., EKTKey) may need to change from time-to-time during 518 the life of a conference, such as when a new participant joins or 519 leaves a conference. Dictating if, when or how often a conference is 520 to be re-keyed is outside the scope of this document, but this 521 framework does accommodate re-keying during the life of a conference. 523 When a Key Distributor decides to rekey a conference, it transmits a 524 specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to 525 each of the conference participants. The endpoint MUST create a new 526 SRTP master key and prepare to send that key inside a Full EKT Field 527 using the new EKTKey. Since it may take some time for all of the 528 endpoints in conference to finish re-keying, senders MUST delay a 529 short period of time before sending media encrypted with the new 530 master key, but it MUST be prepared to make use of the information 531 from a new inbound EKTKey immediately. See Section 2.2.2 of 532 [I-D.ietf-perc-srtp-ekt-diet]. 534 5. Entity Trust 536 It is important to this solution framework that the entities can 537 trust and validate the authenticity of other entities, especially the 538 Key Distributor and endpoints. The details of this are outside the 539 scope of specification but a few possibilities are discussed in the 540 following sections. The key requirements is that endpoints can 541 verify they are connected to the correct Key Distributor for the 542 conference and the Key Distributor can verify the endpoints are the 543 correct endpoints for the conference. 545 Two possible approaches to solve this are Identity Assertions and 546 Certificate Fingerprints. 548 5.1. Identity Assertions 550 WebRTC Identity assertion [I-D.ietf-rtcweb-security-arch] can be used 551 to bind the identity of the user of the endpoint to the fingerprint 552 of the DTLS-SRTP certificate used for the call. This certificate is 553 unique for a given call and a conference. This allows the Key 554 Distributor to ensure that only authorized users participate in the 555 conference. Similarly the Key Distributor can create a WebRTC 556 Identity assertion to bind the fingerprint of the unique certificate 557 used by the Key Distributor for this conference so that the endpoint 558 can validate it is talking to the correct Key Distributor. Such a 559 setup requires an Identity Provider (Idp) trusted by the endpoints 560 and the Key Distributor. 562 5.2. Certificate Fingerprints in Session Signaling 564 Entities managing session signaling are generally assumed to be 565 untrusted in the PERC framework. However, there are some deployment 566 scenarios where parts of the session signaling may be assumed 567 trustworthy for the purposes of exchanging, in a manner that can be 568 authenticated, the fingerprint of an entity's certificate. 570 As a concrete example, SIP [RFC3261] and SDP [RFC4566] can be used to 571 convey the fingerprint information per [RFC5763]. An endpoint's SIP 572 User Agent would send an INVITE message containing SDP for the media 573 session along with the endpoint's certificate fingerprint, which can 574 be signed using the procedures described in [RFC4474] for the benefit 575 of forwarding the message to other entities. Other entities can now 576 verify the fingerprints match the certificates found in the DTLS-SRTP 577 connections to find the identity of the far end of the DTLS-SRTP 578 connection and check that is the authorized entity. 580 Ultimately, if using session signaling, an endpoint's certificate 581 fingerprint would need to be securely mapped to a user and conveyed 582 to the Key Distributor so that it can check that that user is 583 authorized. Similarly, the Key Distributor's certificate fingerprint 584 can be conveyed to endpoint in a manner that can be authenticated as 585 being an authorized Key Distributor for this conference. 587 5.3. Conferences Identification 589 The Key Distributor is responsible for knowing what endpoints are 590 allowed in a given conference. Thus, the Key Distributor and the 591 Media Distributor will need to know endpoint-to-conference mappings, 592 which is enabled by exchanging a conference-specific unique 593 identifier as defined in [I-D.jones-perc-dtls-tunnel]. How this 594 unique identifier is assigned is outside the scope of this document. 596 6. Security Considerations 598 This framework, and the individual protocols defined to support it, 599 must take care to not increase the exposure to Denial of Service 600 (DoS) attacks by untrusted or third-party entities and should take 601 measures to mitigate, where possible, more serious DoS attacks from 602 on-path and off-path attackers. 604 The following section enumerates the kind of attacks that will be 605 considered in the development of this framework's solution. 607 6.1. Third Party Attacks 609 On-path attacks are mitigated by HBH integrity protection and 610 encryption. The integrity protection mitigates packet modification 611 and encryption makes selective blocking of packets harder, but not 612 impossible. 614 Off-path attackers may try connecting to different PERC entities and 615 send specifically crafted packets. A successful attacker might be 616 able to get the Media Distributor to forward such packets. If not 617 making use of HBH authentication on the Media Distributor, such an 618 attack could only be detected in the receiving endpoints where the 619 forged packets would finally be dropped. 621 Another potential attack is a third party claiming to be a Media 622 Distributor, fooling endpoints in to sending packets to the false 623 Media Distributor instead of the correct one. The deceived sending 624 endpoints could incorrectly assuming their packets have been 625 delivered to endpoints when they in fact have not. Further, the 626 false Media Distributor may cascade to another legitimate Media 627 Distributor creating a false version of the real conference. 629 This attack can be mitigated by the false Media Distributor not being 630 authenticated by the Key Distributor during PERC Tunnel 631 establishment. Without the tunnel in place, endpoints will not 632 establish secure associations with the Key Distributor and receive 633 the KEK, causing the conference to not proceed. 635 6.2. Media Distributor Attacks 637 The Media Distributor can attack the session in a number of possible 638 ways. 640 6.2.1. Denial of service 642 Any modification of the end-to-end authenticated data will result in 643 the receiving endpoint getting an integrity failure when performing 644 authentication on the received packet. 646 The Media Distributor can also attempt to perform resource 647 consumption attacks on the receiving endpoint. One such attack would 648 be to insert random SSRC/CSRC values in any RTP packet with an inband 649 key-distribution message attached (i.e., Full EKT Field). Since such 650 a message would trigger the receiver to form a new cryptographic 651 context, the Media Distributor can attempt to consume the receiving 652 endpoints resources. 654 Another denial of service attack is where the Media Distributor 655 rewrites the PT field to indicate a different codec. The effect of 656 this attack is that any payload packetized and encoded according to 657 one RTP payload format is then processed using another payload format 658 and codec. Assuming that the implementation is robust to random 659 input, it is unlikely to cause crashes in the receiving software/ 660 hardware. However, it is not unlikely that such rewriting will cause 661 severe media degradation. 663 For audio formats, this attack is likely to cause highly disturbing 664 audio and/or can be damaging to hearing and playout equipment. 666 6.2.2. Replay Attack 668 Replay attack is when an already received packets from a previous 669 point in the RTP stream is replayed as new packet. This could, for 670 example, allow a Media Distributor to transmit a sequence of packets 671 identified as a user saying "yes", instead of the "no" the user 672 actually said. 674 The mitigation for a replay attack is to prevent old packets beyond a 675 small-to-modest jitter and network re-ordering sized window to be 676 rejected. End-to-end replay protection MUST be provided for the 677 whole duration of the conference. 679 6.2.3. Delayed Playout Attack 681 The delayed playout attack is a variant of the replay attack. This 682 attack is possible even if E2E replay protection is in place. 683 However, due to fact that the Media Distributor is allowed to select 684 a sub-set of streams and not forward the rest to a receiver, such as 685 in forwarding only the most active speakers, the receiver has to 686 accept gaps in the E2E packet sequence. The issue with this is that 687 a Media Distributor can select to not deliver a particular stream for 688 a while. 690 Within the window from last packet forwarded to the receiver and the 691 latest received by the Media Distributor, the Media Distributor can 692 select an arbitrary starting point when resuming forwarding packets. 693 Thus what the media source said can be substantially delayed at the 694 receiver with the receiver believing that it is what was said just 695 now, and only delayed due to transport delay. 697 6.2.4. Splicing Attack 699 The splicing attack is an attack where a Media Distributor receiving 700 multiple media sources splices one media stream into the other. If 701 the Media Distributor is able to change the SSRC without the receiver 702 having any method for verifying the original source ID, then the 703 Media Distributor could first deliver stream A and then later forward 704 stream B under the same SSRC as stream A was previously using. Not 705 allowing the Media Distributor to change the SSRC mitigates this 706 attack. 708 7. IANA Considerations 710 There are no IANA considerations for this document. 712 8. Acknowledgments 714 The authors would like to thank Mo Zanaty and Christian Oien for 715 invaluable input on this document. Also, we would like to 716 acknowledge Nermeen Ismail for serving on the initial versions of 717 this document as a co-author. 719 9. References 721 9.1. Normative References 723 [I-D.ietf-perc-double] 724 Jennings, C., Jones, P., and A. Roach, "SRTP Double 725 Encryption Procedures", draft-ietf-perc-double-01 (work in 726 progress), July 2016. 728 [I-D.ietf-perc-srtp-ekt-diet] 729 Mattsson, J., McGrew, D., Wing, D., and C. Jennings, 730 "Encrypted Key Transport for Secure RTP", draft-ietf-perc- 731 srtp-ekt-diet-01 (work in progress), July 2016. 733 [I-D.jones-perc-dtls-tunnel] 734 Jones, P., "A DTLS Tunnel between Media Distributor and 735 Key Distributor to Facilitate Key Exchange", draft-jones- 736 perc-dtls-tunnel-03 (work in progress), July 2016. 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, 740 DOI 10.17487/RFC2119, March 1997, 741 . 743 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 744 Jacobson, "RTP: A Transport Protocol for Real-Time 745 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 746 July 2003, . 748 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 749 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 750 RFC 3711, DOI 10.17487/RFC3711, March 2004, 751 . 753 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 754 Security (DTLS) Extension to Establish Keys for the Secure 755 Real-time Transport Protocol (SRTP)", RFC 5764, 756 DOI 10.17487/RFC5764, May 2010, 757 . 759 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 760 Real-time Transport Protocol (SRTP)", RFC 6904, 761 DOI 10.17487/RFC6904, April 2013, 762 . 764 9.2. Informative References 766 [I-D.ietf-avtcore-rtp-topologies-update] 767 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 768 ietf-avtcore-rtp-topologies-update-10 (work in progress), 769 July 2015. 771 [I-D.ietf-rtcweb-security-arch] 772 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 773 rtcweb-security-arch-12 (work in progress), June 2016. 775 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 776 A., Peterson, J., Sparks, R., Handley, M., and E. 777 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 778 DOI 10.17487/RFC3261, June 2002, 779 . 781 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 782 Authenticated Identity Management in the Session 783 Initiation Protocol (SIP)", RFC 4474, 784 DOI 10.17487/RFC4474, August 2006, 785 . 787 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 788 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 789 July 2006, . 791 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 792 for Establishing a Secure Real-time Transport Protocol 793 (SRTP) Security Context Using Datagram Transport Layer 794 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 795 2010, . 797 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 798 Transport Protocol (RTP) Header Extension for Client-to- 799 Mixer Audio Level Indication", RFC 6464, 800 DOI 10.17487/RFC6464, December 2011, 801 . 803 Authors' Addresses 805 Paul E. Jones 806 Cisco 807 7025 Kit Creek Rd. 808 Research Triangle Park, North Carolina 27709 809 USA 811 Phone: +1 919 476 2048 812 Email: paulej@packetizer.com 814 David Benham 815 Cisco 816 170 West Tasman Drive 817 San Jose, California 95134 818 USA 820 Email: dbenham@cisco.com 822 Christian Groves 823 Huawei 824 Melbourne 825 Australia 827 Email: Christian.Groves@nteczone.com