idnits 2.17.1 draft-ietf-perc-private-media-framework-01.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 (July 8, 2016) is 2849 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) == Missing Reference: 'TBD' is mentioned on line 736, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-00 == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-00 == Outdated reference: A later version (-04) exists of draft-jones-perc-dtls-tunnel-03 -- 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: January 9, 2017 C. Groves 6 Huawei 7 July 8, 2016 9 A Solution Framework for Private Media in Privacy Enhanced RTP 10 Conferencing 11 draft-ietf-perc-private-media-framework-01 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 January 9, 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 6. Attacks on Privacy Enhanced RTP Conferencing . . . . . . . . 13 77 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 13 78 6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 14 79 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 14 80 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 14 81 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 15 82 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 15 83 7. To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 Switched conferencing is an increasingly popular model for multimedia 95 conferences with multiple participants using a combination of audio, 96 video, text, and other media types. With this model, real-time media 97 flows from conference participants are not mixed, transcoded, 98 transrated, recomposed, or otherwise manipulated by a Media 99 Distributor, as might be the case with a traditional media server or 100 multipoint control unit (MCU). Instead, media flows transmitted by 101 conference participants are simply forwarded by the Media Distributor 102 to each of the other participants, often forwarding only a subset of 103 flows based on voice activity detection or other criteria. In some 104 instances, the Media Distributors may make limited modifications to 105 RTP [RFC3550] headers, for example, but the actual media content 106 (e.g., voice or video data) is unaltered. 108 An advantage of switched conferencing is that Media Distributors can 109 be more easily deployed on general-purpose computing hardware, 110 including virtualized environments in private and public clouds. 111 Deploying conference resources in a public cloud environment might 112 introduce a higher security risk. Whereas traditional conference 113 resources were usually deployed in private networks that were 114 protected, cloud-based conference resources might be viewed as less 115 secure since they are not always physically controlled by those who 116 use them. Additionally, there are usually several ports open to the 117 public in cloud deployments, such as for remote administration, and 118 so on. 120 This document defines a solution framework wherein media privacy is 121 ensured by making it impossible for a media distribution device to 122 gain access to keys needed to decrypt or authenticate the actual 123 media content sent between conference participants. At the same 124 time, the framework allows for the Media Distributors to modify 125 certain RTP headers; add, remove, encrypt, or decrypt RTP header 126 extensions; and encrypt and decrypt RTCP packets. The framework also 127 prevents replay attacks by authenticating each packet transmitted 128 between a given participant and the media distribution device using a 129 unique key per endpoint that is independent from the key for media 130 encryption and authentication. 132 A goal of this document is to define a framework for enhanced privacy 133 in RTP-based conferencing environments while utilizing existing 134 security procedures defined for RTP with minimal enhancements. 136 2. Conventions Used in This Document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119] when they 141 appear in ALL CAPS. These words may also appear in this document in 142 lower case as plain English words, absent their normative meanings. 144 Additionally, this solution framework uses the following conventions, 145 terms and acronyms: 147 End-to-End (E2E): Communications from one endpoint through one or 148 more Media Distribution Devices to the endpoint at the other end. 150 Hop-by-Hop (HBH): Communications between an endpoint and a Media 151 Distribution Device or between Media Distribution Devices. 153 Endpoint: An RTP flow terminating entity that has possession of E2E 154 media encryption keys and terminates E2E encryption. This may 155 include embedded user conferencing equipment or browsers on 156 computers, media gateways, MCUs, media recording device and more that 157 are in the trusted domain for a given deployment. 159 Media Distributor (MD): An RTP middlebox that is not allowed to to 160 have access to E2E encryption keys. It may operate according to any 161 of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] per 162 the constraints defined by the PERC system, which includes, but not 163 limited to, having no access to RTP media unencrypted and having 164 limits on what RTP header 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 may be necessary to for proper conference-to-endpoint 300 mappings, which may or may not be satisfied by getting information 301 directly from the endpoints or via some other means. See Section 7 302 for a related item in the To Do list. 304 The Key Distributor needs to be secured and managed in a way to 305 prevent exploitation by an adversary, as any kind of compromise of 306 the Key Distributor puts the security of the conference at risk. 308 4. Framework for PERC 310 The purpose for this framework is to define a means through which 311 media privacy can be ensured when communicating within a conferencing 312 environment consisting of one or more Media Distributors that only 313 switch, hence not terminate, media. It does not otherwise attempt to 314 hide the fact that a conference between endpoints is taking place. 316 This framework reuses several specified RTP security technologies, 317 including SRTP [RFC3711], PERC EKT [I-D.ietf-perc-srtp-ekt-diet], and 318 DTLS-SRTP [RFC5764]. 320 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 322 This solution framework focuses on the end-to-end privacy and 323 integrity of the participant's media by limiting access to end-to-end 324 key information to trusted entities. However, this framework does 325 give a Media Distributor access to RTP headers and all or most header 326 extensions, as well as the ability to modify a certain subset of 327 those headers and to add header extensions. Packets received by a 328 Media Distributor or an endpoint are authenticated hop-by-hop. 330 To enable all of the above, this framework defines the use of two 331 security contexts and two associated encryption keys; an "inner" key 332 (E2E Key(i); i={a given endpoint}) for authenticated encryption of 333 RTP media between endpoints and an "outer" key (HBH Key(j); j={a 334 given hop}) for the hop between an endpoint and a Media Distributor 335 or between Media Distributor. Reference the following figure. 337 +-------------+ +-------------+ 338 | |################################| | 339 | Media |------------------------------->| Media | 340 | Distributor |<-------------------------------| Distributor | 341 | X |################################| Y | 342 | | HBH Key (XY) | | 343 +-------------+ +-------------+ 344 # ^ | # # ^ | # 345 # | | # HBH HBH # | | # 346 # | | # <== Key(AX) Key(YB) ==> # | | # 347 # | | # # | | # 348 # |<+--#---- E2E Key (A) E2E Key (B) ---#->| | # 349 # | | # # | | # 350 # | v # # | v # 351 +-------------+ +-------------+ 352 | Endpoint A | | Endpoint B | 353 +-------------+ +-------------+ 355 E2E and HBH Keys Used for Authenticated Encryption 357 The PERC Double draft specification [I-D.ietf-perc-double] uses 358 standard SRTP keying material and recommended cryptographic 359 transform(s) to first form the inner, end-to-end SRTP cryptographic 360 context. That end-to-end SRTP cryptographic context MAY be used to 361 encrypt some RTP header extensions along with RTP media content. The 362 output of this is treated like an RTP packet and encrypted again 363 using the outer hop-by-hop cryptographic context. The endpoint 364 executes the entire Double operation while the Media Distributor just 365 performs the outer, hop-by-hop operation. 367 RTCP can only be encrypted hop-by-hop, not end-to-end. This 368 framework introduces no additional step for RTCP authenticated 369 encryption, so the procedures needed are specified in [RFC3711] and 370 use the same outer, hop-by-hop cryptographic context chosen in the 371 Double operation described above. 373 4.2. E2E Key Confidentiality 375 To ensure the confidentiality of E2E keys shared between endpoints, 376 endpoints will make use of a common Key Encryption Key (KEK) that is 377 known only by the trusted entities in a conference. That KEK, 378 defined in the PERC EKT [I-D.ietf-perc-srtp-ekt-diet] as the EKT Key, 379 will be used to subsequently encrypt SRTP master keys used for E2E 380 authenticated encryption (E2E Key(i); i={a given endpoint}) of media 381 sent by a given endpoint. 383 +---------------------+------------+-------+-------+------------+ 384 | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | 385 +---------------------+------------+-------+-------+------------+ 386 | KEK | Yes | No | No | Yes | 387 +---------------------+------------+-------+-------+------------+ 388 | E2E Key (i) | Yes | No | No | Yes | 389 +---------------------+------------+-------+-------+------------+ 390 | HBH Key (A<=>MD X) | Yes | Yes | No | No | 391 +---------------------+------------+-------+-------+------------+ 392 | HBH Key (B<=>MD Y) | No | No | Yes | Yes | 393 +---------------------+------------+---------------+------------+ 395 Figure 2: Keys per Entity 397 4.3. E2E Keys and Endpoint Operations 399 Any given RTP media flow can be identified by its SSRC, and endpoints 400 might send more than one at a time and change the mix of media flows 401 transmitted during the life of a conference. 403 Thus, endpoints MUST maintain a list of SSRCs from received RTP flows 404 and each SSRC's associated E2E Key(i) information. Following a 405 change of the KEK (i.e., EKT Key), prior E2E Key(i) information 406 SHOULD be retained for a period long enough to ensure that late- 407 arriving or out-of-order packets from other endpoints can be 408 successfully decrypted. The endpoint MUST discard the E2E Key(i) and 409 KEK information no later than when it leaves the conference. 411 If there is a need to encrypt one or more RTP header extensions end- 412 to-end, an encryption key is derived from the end-to-end SRTP master 413 key to encrypt header extensions as per [RFC6904]. The Media 414 Distributor will not be able use the information contained in those 415 header extensions encrypted with E2E keys. See Section 7 for a 416 related item in the To Do list. 418 4.4. HBH Keys and Hop Operations 420 To ensure the integrity of transmitted media packets, this framework 421 requires that every packet be authenticated hop-by-hop (HBH) between 422 an endpoint and a Media Distributor, as well between Media 423 Distributors. The authentication key used for hop-by-hop 424 authentication is derived from an SRTP master key shared only on the 425 respective hop (HBH Key(j); j={a given hop}). Each HBH Key(j) is 426 distinct per hop and no two hops ever intentionally use the same SRTP 427 master key. 429 Using hop-by-hop authentication gives the Media Distributor the 430 ability to change certain RTP header values. Which values the Media 431 Distributor can change in the RTP header are defined in 432 [I-D.ietf-perc-double]. RTCP can only be encrypted, giving the Media 433 Distributor the flexibility to forward RTCP content unchanged, 434 transmit compound RTCP packets or to initiate RTCP packets for 435 reporting statistics or conveying other information. Performing hop- 436 by-hop authentication for all RTP and RTCP packets also helps provide 437 replay protection (see Section 6). 439 If there is a need to encrypt one or more RTP header extensions hop- 440 by-hop, an encryption key is derived from the hop-by-hop SRTP master 441 key to encrypt header extensions as per [RFC6904]. This will still 442 give the Media Distributor visibility into header extensions, such as 443 the one used to determine audio level [RFC6464] of conference 444 participants. Note that when RTP header extensions are encrypted, 445 all hops - in the untrusted domain at least - will need to decrypt 446 and re-encrypt these encrypted header extensions. 448 4.5. Key Exchange 450 To facilitate key exchange required to establish or generate an E2E 451 key and a HBH key for an endpoint and the same HBH key for the Media 452 Distributor, this framework utilizes a DTLS-SRTP [RFC5764] 453 association between an endpoint and the Key Distributor. To 454 establish this association, an endpoint will send DTLS-SRTP messages 455 to the Media Distributor which will then forward them to the Media 456 Distributor as defined in [I-D.jones-perc-dtls-tunnel]. The Key 457 Encryption Key (KEK) (i.e., EKT Key) is also conveyed by the Key 458 Distributor over the DTLS association to endpoints via procedures 459 defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet]. 461 Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media 462 Distributor to establish HBH keys for transmitting RTP and RTCP 463 packets that peer Media Distributor. The Key Distributor does not 464 facilitate establishing HBH keys for use between Media Distributors. 466 4.5.1. Initial Key Exchange and Key Distributor 468 The procedures defined in DTLS Tunnel for PERC 469 [I-D.jones-perc-dtls-tunnel] establish one or more DTLS tunnels 470 between the Media Distributor and Key Distributor, making it is 471 possible for the Media Distributor to facilitate the establishment of 472 a secure DTLS association between each endpoint and the Key 473 Distributor as shown the following figure. The DTLS association 474 between endpoints and the Key Distributor will enable each endpoint 475 to receive E2E key information, Key Encryption Key (KEK) information 476 (i.e., EKT Key), and HBH key information. At the same time, the Key 477 Distributor can securely provide the HBH key information to the Media 478 Distributor. The key information summarized here may include the 479 SRTP master key, SRTP master salt, and the negotiated cryptographic 480 transform. 482 +-----------+ 483 KEK info | Key | HBH Key info to 484 to Endpoints |Distributor| Endpoints & Media Distributor 485 +-----------+ 486 # ^ ^ # 487 # | | #-DTLS Tunnel 488 # | | # 489 +-----------+ +-----------+ +-----------+ 490 | Endpoint | DTLS | Media | DTLS | Endpoint | 491 | KEK |<------------|Distributor|------------>| KEK | 492 | HBH Key(j)| to Key Dist | HBH Keys | to Key Dist | HBH Key(j)| 493 +-----------+ +-----------+ +-----------+ 495 Figure 3: Exchanging Key Information Between Entities 497 Endpoints will establish a DTLS-SRTP association over the RTP 498 session's media ports for the purposes of key information exchange 499 with the Key Distributor. The Media Distributor will not terminate 500 the DTLS signaling, but will instead forward DTLS packets received 501 from an endpoint on to the Key Distributor (and vice versa) via a 502 tunnel established between Media Distributor and the Key Distributor. 503 This tunnel used to encapsulate the DTLS-SRTP signaling between the 504 Key Distributor and endpoints will also be used to convey HBH key 505 information from the Key Distributor to the Media Distributor, so no 506 additional protocol or interface is required. 508 4.5.2. Key Exchange during a Conference 510 Following the initial key information exchange with the Key 511 Distributor, endpoints will be able to encrypt media end-to-end with 512 their E2E Key(i), sending that E2E Key(i) to other endpoints 513 encrypted with KEK, and will be able to encrypt and authenticate RTP 514 packets using local HBH Key(j). The procedures defined do not allow 515 the Media Distributor to gain access to the KEK information, 516 preventing it from gaining access to any endpoint's E2E key and 517 subsequently decrypting media. 519 The KEK (i.e., EKT Key) may need to change from time-to-time during 520 the life of a conference, such as when a new participant joins or 521 leaves a conference. Dictating if, when or how often a conference is 522 to be re-keyed is outside the scope of this document, but this 523 framework does accommodate re-keying during the life of a conference. 525 When a Key Distributor decides to rekey a conference, it transmits a 526 specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to 527 each of the conference participants. The endpoint MUST create a new 528 SRTP master key and prepare to send that key inside a Full EKT Field 529 using the new EKT Key. Since it may take some time for all of the 530 endpoints in conference to finish re-keying, senders MUST delay a 531 short period of time before sending media encrypted with the new 532 master key, but it MUST be prepared to make use of the information 533 from a new inbound EKT Key immediately. See Section 2.2.2 of 534 [I-D.ietf-perc-srtp-ekt-diet]. 536 5. Entity Trust 538 It is important to this solution framework that the entities can 539 trust and validate the authenticity of other entities, especially the 540 Key Distributor and endpoints. The details of this are outside the 541 scope of specification but a few possibilities are discussed in the 542 following sections. The key requirements is that endpoints can 543 verify they are connected to the correct Key Distributor for the 544 conference and the Key Distributor can verify the endpoints are the 545 correct endpoints for the conference. 547 Two possible approaches to solve this are Identity Assertions and 548 Certificate Fingerprints. 550 5.1. Identity Assertions 552 WebRTC Identity assertion (EDITOR NOTE: add I-D reference) can be 553 used to bind the identity of the user of the endpoint to the 554 fingerprint of the DTLS-SRTP certificate used for the call. This 555 certificate is unique for a given call and a conference. This allows 556 the Key Distributor to ensure that only authorized users participate 557 in the conference. Similarly the Key Distributor can create a WeBRTC 558 Identity assertion bound the fingerprint of the unique certificate 559 used by the Key Distributor for this conference so that the endpoint 560 can validate it is talking to the correct 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 6. Attacks on Privacy Enhanced RTP Conferencing 589 This framework, and the individual protocols defined to support it, 590 must take care to not increase the exposure to Denial of Service 591 (DoS) attacks by untrusted or third-party entities and should take 592 measures to mitigate, where possible, more serious DoS attacks from 593 on-path and off-path attackers. 595 The following section enumerates the kind of attacks that will be 596 considered in the development of this framework's solution. 598 6.1. Third Party Attacks 600 On-path attacks are mitigated by HBH integrity protection and 601 encryption. The integrity protection mitigates packet modification 602 and encryption makes selective blocking of packets harder, but not 603 impossible. 605 Off-path attackers may try connecting to different PERC entities and 606 send specifically crafted packets. A successful attacker might be 607 able to get the Media Distributor to forward such packets. If not 608 making use of HBH authentication on the Media Distributor, such an 609 attack could only be detected in the receiving endpoints where the 610 forged packets would finally be dropped. 612 Another potential attack is a third party claiming to be a Media 613 Distributor, fooling endpoints in to sending packets to the false 614 Media Distributor instead of the correct one. The deceived sending 615 endpoints could incorrectly assuming their packets have been 616 delivered to endpoints when they in fact have not. Further, the 617 false Media Distributor may cascade to another legitimate Media 618 Distributor creating a false version of the real conference. 620 This attack can be mitigated by the false Media Distributor not being 621 authenticated by the Key Distributor during PERC Tunnel 622 establishment. Without the tunnel in place, endpoints will not 623 establish secure associations with the Key Distributor and receive 624 the KEK, causing the conference to not proceed. 626 6.2. Media Distributor Attacks 628 The Media Distributor can attack the session in a number of possible 629 ways. 631 6.2.1. Denial of service 633 Any modification of the end-to-end authenticated data will result in 634 the receiving endpoint getting an integrity failure when performing 635 authentication on the received packet. 637 The Media Distributor can also attempt to perform resource 638 consumption attacks on the receiving endpoint. One such attack would 639 be to insert random SSRC/CSRC values in any RTP packet with an inband 640 key-distribution message attached (i.e., Full EKT Field). Since such 641 a message would trigger the receiver to form a new cryptographic 642 context, the Media Distributor can attempt to consume the receiving 643 endpoints resources. 645 Another denial of service attack is where the Media Distributor 646 rewrites the PT field to indicate a different codec. The effect of 647 this attack is that any payload packetized and encoded according to 648 one RTP payload format is then processed using another payload format 649 and codec. Assuming that the implementation is robust to random 650 input, it is unlikely to cause crashes in the receiving software/ 651 hardware. However, it is not unlikely that such rewriting will cause 652 severe media degradation. 654 For audio formats, this attack is likely to cause highly disturbing 655 audio and/or can be damaging to hearing and playout equipment. 657 6.2.2. Replay Attack 659 Replay attack is when an already received packets from a previous 660 point in the RTP stream is replayed as new packet. This could, for 661 example, allow a Media Distributor to transmit a sequence of packets 662 identified as a user saying "yes", instead of the "no" the user 663 actually said. 665 The mitigation for a replay attack is to prevent old packets beyond a 666 small-to-modest jitter and network re-ordering sized window to be 667 rejected. End-to-end replay protection MUST be provided for the 668 whole duration of the conference. 670 6.2.3. Delayed Playout Attack 672 The delayed playout attack is a variant of the replay attack. This 673 attack is possible even if E2E replay protection is in place. 674 However, due to fact that the Media Distributor is allowed to select 675 a sub-set of streams and not forward the rest to a receiver, such as 676 in forwarding only the most active speakers, the receiver has to 677 accept gaps in the E2E packet sequence. The issue with this is that 678 a Media Distributor can select to not deliver a particular stream for 679 a while. 681 Within the window from last packet forwarded to the receiver and the 682 latest received by the Media Distributor, the Media Distributor can 683 select an arbitrary starting point when resuming forwarding packets. 684 Thus what the media source said can be substantially delayed at the 685 receiver with the receiver believing that it is what was said just 686 now, and only delayed due to transport delay. 688 6.2.4. Splicing Attack 690 The splicing attack is an attack where a Media Distributor receiving 691 multiple media sources splices one media stream into the other. If 692 the Media Distributor is able to change the SSRC without the receiver 693 having any method for verifying the original source ID, then the 694 Media Distributor could first deliver stream A and then later forward 695 stream B under the same SSRC as stream A was previously using. Not 696 allowing the Media Distributor to change the SSRC mitigates this 697 attack. 699 7. To-Do List 701 o The mapping of endpoints-to-conference identifiers may need to be 702 conveyed in the framework. Need Revisit this text after a design 703 choice is made between alternatives. 705 o Consider adding a list of RTP header extensions that should/must 706 not be E2E encrypted. 708 o Endpoints, Key Distributor and Media Distributor provider must 709 securely convey their respective certificate information directly 710 or indirectly via some means, such as via an identity service 711 provider. 713 o If as in "Double" draft, the ROC value is no longer in the clear 714 and associated with the "outer" protection scheme, we may need to 715 require that the Media Distributor maintain a separate ROC value 716 for each SSRC sent to each endpoint. This ROC value should start 717 at 0 regardless of the sequence number in that first packet sent 718 to an endpoint. 720 o Investigate adding ability to enable the transmission of one-way 721 media from a non-trusted device (e.g., announcements). One 722 possible solution is to have the Key Distributor send an "ekt_key" 723 message that is explicitly labeled for receive-only and giving 724 that to announcement servers. A possible approach would be to 725 define EKT Keys with a SPI > 32000, for example, for this purpose 726 and endpoints should only use those EKT Keys to decrypt Full EKT 727 Fields received from such transmitters. Endpoints would never 728 send media with EKT Keys with those SPI values. 730 8. IANA Considerations 732 There are no IANA considerations for this document. 734 9. Security Considerations 736 [TBD] 738 10. Acknowledgments 740 The authors would like to thank Mo Zanaty and Christian Oien for 741 invaluable input on this document. Also, we would like to 742 acknowledge Nermeen Ismail for serving on the initial versions of 743 this document as a co-author. 745 11. References 747 11.1. Normative References 749 [I-D.ietf-perc-double] 750 Jennings, C., Jones, P., and A. Roach, "SRTP Double 751 Encryption Procedures", draft-ietf-perc-double-00 (work in 752 progress), May 2016. 754 [I-D.ietf-perc-srtp-ekt-diet] 755 Mattsson, J., McGrew, D., Wing, D., and C. Jennings, 756 "Encrypted Key Transport for Secure RTP", draft-ietf-perc- 757 srtp-ekt-diet-00 (work in progress), May 2016. 759 [I-D.jones-perc-dtls-tunnel] 760 Jones, P., "DTLS Tunnel between Media Distribution Device 761 and Key Management Function to Facilitate Key Exchange", 762 draft-jones-perc-dtls-tunnel-03 (work in progress), July 763 2016. 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 767 RFC2119, March 1997, 768 . 770 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 771 Jacobson, "RTP: A Transport Protocol for Real-Time 772 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 773 July 2003, . 775 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 776 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 777 RFC 3711, DOI 10.17487/RFC3711, March 2004, 778 . 780 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 781 Security (DTLS) Extension to Establish Keys for the Secure 782 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 783 10.17487/RFC5764, May 2010, 784 . 786 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 787 Real-time Transport Protocol (SRTP)", RFC 6904, DOI 788 10.17487/RFC6904, April 2013, 789 . 791 11.2. Informative References 793 [I-D.ietf-avtcore-rtp-topologies-update] 794 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 795 ietf-avtcore-rtp-topologies-update-10 (work in progress), 796 July 2015. 798 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 799 A., Peterson, J., Sparks, R., Handley, M., and E. 800 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 801 DOI 10.17487/RFC3261, June 2002, 802 . 804 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 805 Authenticated Identity Management in the Session 806 Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/ 807 RFC4474, August 2006, 808 . 810 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 811 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 812 July 2006, . 814 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 815 for Establishing a Secure Real-time Transport Protocol 816 (SRTP) Security Context Using Datagram Transport Layer 817 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 818 2010, . 820 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 821 Transport Protocol (RTP) Header Extension for Client-to- 822 Mixer Audio Level Indication", RFC 6464, DOI 10.17487/ 823 RFC6464, December 2011, 824 . 826 Authors' Addresses 828 Paul E. Jones 829 Cisco 830 7025 Kit Creek Rd. 831 Research Triangle Park, North Carolina 27709 832 USA 834 Phone: +1 919 476 2048 835 Email: paulej@packetizer.com 837 David Benham 838 Cisco 839 170 West Tasman Drive 840 San Jose, California 95134 841 USA 843 Email: dbenham@cisco.com 844 Christian Groves 845 Huawei 846 Melbourne 847 Australia 849 Email: Christian.Groves@nteczone.com