idnits 2.17.1 draft-ietf-perc-private-media-framework-00.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 13, 2016) is 2904 days in the past. Is this intentional? 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 701, 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-02 -- 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 (==), 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 D. Benham 4 Intended status: Standards Track Cisco 5 Expires: November 14, 2016 May 13, 2016 7 A Solution Framework for Private Media in Privacy Enhanced RTP 8 Conferencing 9 draft-ietf-perc-private-media-framework-00 11 Abstract 13 This document describes a solution framework for ensuring that media 14 confidentiality and integrity are maintained end-to-end within the 15 context of a switched conferencing environment where media 16 distribution devices are not trusted with the end-to-end media 17 encryption keys. The solution aims to build upon existing security 18 mechanisms defined for the real-time transport protocol (RTP). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 14, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 4 57 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 58 3.1.1. MDD . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6 60 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 6 61 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2.2. KMF . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 7 65 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 8 66 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9 67 4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 9 68 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 69 4.5.1. Initial Key Exchange and KMF . . . . . . . . . . . . 10 70 4.5.2. Key Exchange during a Conference . . . . . . . . . . 11 71 5. Entity Trust . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 12 73 5.2. Certificate Fingerprints in Session Signaling . . . . . . 12 74 6. Attacks on Privacy Enhanced RTP Conferencing . . . . . . . . 12 75 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 13 76 6.2. MDD Attacks . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 13 78 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 14 79 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 14 80 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 14 81 7. To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 11.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Switched conferencing is an increasingly popular model for multimedia 93 conferences with multiple participants using a combination of audio, 94 video, text, and other media types. With this model, real-time media 95 flows from conference participants are not mixed, transcoded, 96 transrated, recomposed, or otherwise manipulated by a media 97 distribution device (MDD), as might be the case with a traditional 98 media server or multipoint control unit (MCU). Instead, media flows 99 transmitted by conference participants are simply forwarded by the 100 MDD to each of the other participants, often forwarding only a subset 101 of flows based on voice activity detection or other criteria. In 102 some instances, the MDDs may make limited modifications to RTP 103 [RFC3550] headers, for example, but the actual media content (e.g., 104 voice or video data) is unaltered. 106 An advantage of switched conferencing is that media distribution 107 devices can be more easily deployed on general-purpose computing 108 hardware, including virtualized environments in private and public 109 clouds. Deploying conference resources in a public cloud environment 110 might introduce a higher security risk. Whereas traditional 111 conference resources were usually deployed in private networks that 112 were protected, cloud-based conference resources might be viewed as 113 less secure since they are not always physically controlled by those 114 who use them. Additionally, there are usually several ports open to 115 the public in cloud deployments, such as for remote administration, 116 and so on. 118 This document defines a solution framework wherein media privacy is 119 ensured by making it impossible for an media distribution device to 120 gain access to keys needed to decrypt or authenticate the actual 121 media content sent between conference participants. At the same 122 time, the framework allows for the media distribution device to 123 modify certain RTP headers; add, remove, encrypt, or decrypt RTP 124 header extensions; and encrypt and decrypt RTCP packets. The 125 framework also prevents replay attacks by authenticating each packet 126 transmitted between a given participant and the media distribution 127 device using a unique key per endpoint that is independent from the 128 key for media encryption and authentication. 130 A goal of this document is to define a framework for enhanced privacy 131 in RTP-based conferencing environments while utilizing existing 132 security procedures defined for RTP with minimal enhancements. 134 2. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119] when they 139 appear in ALL CAPS. These words may also appear in this document in 140 lower case as plain English words, absent their normative meanings. 142 Additionally, this solution framework uses the following conventions, 143 terms and acronyms: 145 E2E (End-to-End): Communications from one endpoint through one or 146 more Media Distribution Devices to the endpoint at the other end. 148 HBH (Hop-by-Hop): Communications between an endpoint and an Media 149 Distribution Device or between Media Distribution Devices. 151 Endpoint: An RTP flow terminating entity that has possession of E2E 152 media encryption keys and terminates E2E encryption. This may 153 include embedded user conferencing equipment or browsers on 154 computers, media gateways, MCUs, media recording device and more that 155 are in the trusted domain for a given deployment. 157 MDD (Media Distribution Device): An RTP middlebox that is not allowed 158 to to have access to E2E encryption keys. It may operate according 159 to any of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] 160 per the constraints defined by the PERC system, which includes, but 161 not limited to, having no access to RTP media unencrypted and having 162 limits on what RTP header field it can alter. 164 KMF (Key Management Function): An entity that is a logical function 165 which passes keying material and related information to endpoints and 166 Media Distribution Devices that is appropriate for each. The KMF 167 might be co-resident with another entity trusted with E2E keying 168 material. 170 Conference: Two or more participants communicating via trusted 171 endpoints to exchange RTP flows through one or more Media 172 Distribution Devices. 174 Third Party: Any entity that is not an Endpoint, MDD, KMF or Call 175 Processing entity as described in this document. 177 3. PERC Entities and Trust Model 179 The following figure depicts the trust relationships, direct or 180 indirect, between entities described in the subsequent sub-sections. 181 Note that these entities may be co-located or further divided into 182 multiple, separate physical devices. 184 Please note that some entities classified as untrusted in the simple, 185 general deployment scenario used most commonly in this document might 186 be considered trusted in other deployments. This document does not 187 preclude such scenarios, but will keep the definitions and examples 188 focused by only using the the simple, most general deployment 189 scenario. 191 | 192 +----------+ | +-----------------+ 193 | Endpoint | | | Call Processing | 194 +----------+ | +-----------------+ 195 | 196 | 197 +----------------+ | +--------------------+ 198 | Key Management | | | Media Distribution | 199 | Function | | | Device | 200 +----------------+ | +--------------------+ 201 | 202 Trusted | Untrusted 203 Entities | Entities 204 | 206 Figure 1: Trusted and Untrusted Entities in PERC 208 3.1. Untrusted Entities 210 The architecture described in this framework document enables 211 conferencing infrastructure to be hosted in domains, such as in a 212 cloud conferencing provider's facilities, where the trustworthiness 213 is below the level needed to assume the privacy of participant's 214 media will not be compromised. The conferencing infrastructure in 215 such a domain is still trusted with reliably connecting the 216 participants together in a conference, but not trusted with keying 217 material needed to decrypt any of the participant's media. Entities 218 in such lower trustworthiness domains will simply be referred to as 219 untrusted entities from this point forward. This does not mean that 220 they are completely untrusted as they may be trusted with most non- 221 media related aspects of hosting a conference. 223 3.1.1. MDD 225 A Media Distribution Device (MDD) forwards RTP flows between 226 endpoints in the conference while performing per-hop authentication 227 of each RTP packet. The MDD may need access to one or more RTP 228 headers or header extensions, potentially adding or modifying a 229 certain subset. The MDD will also relay secured messaging between 230 the endpoints and the key management function and will acquire per- 231 hop key information from the KMF. The actual media content MUST NOT 232 not be decryptable by an MDD, so it is untrusted to have access to 233 the E2E media encryption keys, which this framework's key exchange 234 mechanisms will prevent. 236 An endpoint's ability to join a conference hosted by an MDD MUST NOT 237 alone be interpreted as being authorized to have access to the E2E 238 media encryption keys, as the MDD does not have the ability to 239 determine whether an endpoint is authorized. 241 An MDD MUST perform its role in properly forwarding media packets 242 while taking measures to mitigate the adverse effects of denial of 243 service attacks (refer to Section 6), etc, to a level equal to or 244 better than traditional conferencing (i.e. pre-PERC) deployments. 246 An MDD or associated conferencing infrastructure may also initiate or 247 terminate various conference control related messaging, which is 248 outside the scope of this framework document. 250 3.1.2. Call Processing 252 The call processing function is untrusted in the simple, general 253 deployment scenario. When a physical subset of the call processing 254 function resides in facilities outside the trusted domain, it should 255 not be trusted to have access to E2E key information. 257 The call processing function may include the processing of call 258 signaling messages, as well as the signing of those messages. It may 259 also authenticate the endpoints for the purpose of call signaling and 260 subsequently joining of a conference hosted through one or more MDDs. 261 Call processing may optionally ensure the privacy of call signaling 262 messages between itself, the endpoint, and other entities. 264 In any deployment scenario where the call processing function is 265 considered trusted, the call processing function MUST ensure the 266 integrity of received messages before forwarding to other entities. 268 3.2. Trusted Entities 270 From the PERC model system perspective, entities considered trusted 271 (refer to Figure 1) can be in possession of the E2E media encryption 272 key(s) for one or more conferences. 274 3.2.1. Endpoint 276 An endpoint is considered trusted and will have access to E2E key 277 information. While it is possible for an endpoint to be compromised, 278 subsequently performing in undesired ways, defining endpoint 279 resistance to compromise is outside the scope of this document. 280 Endpoints will take measures to mitigate the adverse effects of 281 denial of service attacks (refer to Section 6) from other entities, 282 including from other endpoints, to a level equal to or better than 283 traditional conference (i.e., pre-PERC) deployments. 285 3.2.2. KMF 287 The KMF, which may be collocated with an endpoint or exist 288 standalone, is responsible for providing key information to endpoints 289 for both end-to-end and hop-by-hop security and for providing key 290 information to MDDs for the hop-by-hop security. 292 Interaction between the KMF and the call processing function may be 293 necessary to for proper conference-to-endpoint mappings, which may or 294 may not be satisfied by getting information directly from the 295 endpoints or via some other means. See Section 7 for a related item 296 in the To Do list. 298 The KMF needs to be secured and managed in a way to prevent 299 exploitation by an adversary, as any kind of compromise of the KMF 300 puts the security of the conference at risk. 302 4. Framework for PERC 304 The purpose for this framework is to define a means through which 305 media privacy can be ensured when communicating within a conferencing 306 environment consisting of one or more MDDs that only switch, hence 307 not terminate, media. It does not otherwise attempt to hide the fact 308 that a conference between endpoints is taking place. 310 This framework reuses several specified RTP security technologies, 311 including SRTP [RFC3711], PERC EKT [I-D.ietf-perc-srtp-ekt-diet], and 312 DTLS-SRTP [RFC5764]. 314 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 316 This solution framework focuses on the end-to-end privacy and 317 integrity of the participant's media by limiting access to end-to-end 318 key information to trusted entities. However, this framework does 319 give an MDD access to RTP headers and all or most header extensions, 320 as well as the ability to modify a certain subset of those headers 321 and to add header extensions. Packets received by an MDD or an 322 endpoint are authenticated hop-by-hop. 324 To enable all of the above, this framework defines the use of two 325 security contexts and two associated encryption keys; an "inner" key 326 (E2E Key(i); i={a given endpoint}) for authenticated encryption of 327 RTP media between endpoints and an "outer" key (HBH Key(j); j={a 328 given hop}) for the hop between an endpoint and an MDD or between 329 MDDs. Reference the following figure. 331 +--------+ HBH +-----+ HBH +-----+ HBH +--------+ 332 | |=============| |=========| |=============| | 333 |Endpoint|-E2E Key(A)->| MDD |-------->| MDD |------------>|Endpoint| 334 | A |<------------| X |<--------| Y |<-E2E Key(B)-| B | 335 | |=============| |=========| |=============| | 336 +--------+ Key(AX) +-----+ Key(XY) +-----+ Key(YB) +--------+ 338 E2E and HBH Keys Used for Authenticated Encryption 340 The PERC Double draft specification [I-D.ietf-perc-double] uses 341 standard SRTP keying material and recommended cryptographic 342 transform(s) to first form the inner, end-to-end SRTP cryptographic 343 context. That end-to-end SRTP cryptographic context MAY be used to 344 encrypt some RTP header extensions along with RTP media content. The 345 output of this is treated like an RTP packet and encrypted again 346 using the outer hop-by-hop cryptographic context. The endpoint 347 executes the entire Double operation while the MDD just performs the 348 outer, hop-by-hop operation. 350 RTCP can only be encrypted hop-by-hop, not end-to-end. This 351 framework introduces no additional step for RTCP authenticated 352 encryption, so the procedures needed are specified in [RFC3711] and 353 use the same outer, hop-by-hop cryptographic context chosen in the 354 Double operation described above. 356 4.2. E2E Key Confidentiality 358 To ensure the confidentiality of E2E keys shared between endpoints, 359 endpoints will make use of a common Key Encryption Key (KEK) that is 360 known only by the trusted entities in a conference. That KEK, 361 defined in the PERC EKT [I-D.ietf-perc-srtp-ekt-diet] as the EKT Key, 362 will be used to subsequently encrypt SRTP master keys used for E2E 363 authenticated encryption (E2E Key(i); i={a given endpoint}) of media 364 sent by a given endpoint. 366 +---------------------+------------+-------+-------+------------+ 367 | Key / Entity | Endpoint A | MDD X | MDD Y | Endpoint B | 368 +---------------------+------------+---------------+------------+ 369 | KEK | Yes | No | No | Yes | 370 +---------------------+------------+---------------+------------+ 371 | E2E Key (i) | Yes | No | No | Yes | 372 +---------------------+------------+---------------+------------+ 373 | HBH Key (A<=>MDD X) | Yes | Yes | No | No | 374 +---------------------+------------+---------------+------------+ 375 | HBH Key (B<=>MDD Y) | No | No | Yes | Yes | 376 +---------------------+------------+---------------+------------+ 378 Figure 2: Keys per Entity 380 4.3. E2E Keys and Endpoint Operations 382 Any given RTP media flow can be identified by its SSRC, and endpoints 383 might send more than one at a time and change the mix of media flows 384 transmitted during the life of a conference. 386 Thus, endpoints MUST maintain a list of SSRCs from received RTP flows 387 and each SSRC's associated E2E Key(i) information. Following a 388 change of the KEK (i.e., EKT Key), prior E2E Key(i) information 389 SHOULD be retained for a period long enough to ensure that late- 390 arriving or out-of-order packets from other endpoints can be 391 successfully decrypted. The endpoint MUST discard the E2E Key(i) and 392 KEK information no later than when it leaves the conference. 394 If there is a need to encrypt one or more RTP header extensions end- 395 to-end, an encryption key is derived from the end-to-end SRTP master 396 key to encrypt header extensions as per [RFC6904]. The MDD will not 397 be able use the information contained in those header extensions 398 encrypted with E2E keys. See Section 7 for a related item in the To 399 Do list. 401 4.4. HBH Keys and Hop Operations 403 To ensure the integrity of transmitted media packets, this framework 404 requires that every packet be authenticated hop-by-hop (HBH) between 405 an endpoint and an MDD, as well between MDDs. The authentication key 406 used for hop-by-hop authentication is derived from an SRTP master key 407 shared only on the respective hop (HBH Key(j); j={a given hop}). 408 Each HBH Key(j) is distinct per hop and no two hops ever 409 intentionally use the same SRTP master key. 411 Using hop-by-hop authentication gives the MDD the ability to change 412 certain RTP header values. Which values the MDD can change in the 413 RTP header are defined in [I-D.ietf-perc-double]. RTCP can only be 414 encrypted, giving the MDD the flexibility to forward RTCP content 415 unchanged, transmit compound RTCP packets or to initiate RTCP packets 416 for reporting statistics or conveying other information. Performing 417 hop-by-hop authentication for all RTP and RTCP packets also helps 418 provide replay protection (see Section 6). 420 If there is a need to encrypt one or more RTP header extensions hop- 421 by-hop, an encryption key is derived from the hop-by-hop SRTP master 422 key to encrypt header extensions as per [RFC6904]. This will still 423 give the switching MDD visibility into header extensions, such as the 424 one used to determine audio level [RFC6464] of conference 425 participants. Note that when RTP header extensions are encrypted, 426 all hops - in the untrusted domain at least - will need to decrypt 427 and re-encrypt these encrypted header extensions. 429 4.5. Key Exchange 431 To facilitate key exchange required to establish or generate an E2E 432 key and a HBH key for an endpoint and the same HBH key for the MDD, 433 this framework utilizes a DTLS-SRTP [RFC5764] association between an 434 endpoint and the KMF. To establish this association, an endpoint 435 will send DTLS-SRTP messages to the MDD which will then forward them 436 to the MDD as defined in [I-D.jones-perc-dtls-tunnel]. The Key 437 Encryption Key (KEK) (i.e., EKT Key) is also conveyed by the KMF over 438 the DTLS association to endpoints via procedures defined in PERC EKT 439 [I-D.ietf-perc-srtp-ekt-diet]. 441 MDDs use DTLS-SRTP [RFC5764] directly with a peer MDD to establish 442 HBH keys for transmitting RTP and RTCP packets that peer MDD. The 443 KMF does not facilitate establishing HBH keys for use between MDDs. 445 4.5.1. Initial Key Exchange and KMF 447 The procedures defined in DTLS Tunnel for PERC 448 [I-D.jones-perc-dtls-tunnel] establish one or more DTLS tunnels 449 between the MDD and KMF, making it is possible for the MDD to 450 facilitate the establishment of a secure DTLS association between 451 each endpoint and the KMF as shown the following figure. The DTLS 452 association between endpoints and the KMF will enable each endpoint 453 to receive E2E key information, Key Encryption Key (KEK) information 454 (i.e., EKT Key), and HBH key information. At the same time, the KMF 455 can securely provide the HBH key information to the MDD. The key 456 information summarized here may include the SRTP master key, SRTP 457 master salt, and the negotiated cryptographic transform. 459 KEK info +---------+ HBH Key info 460 to endpoints | KMF | to endpoints & MDD 461 +---------+ 462 | ^ ^ | 463 | | | |-DTLS Tunnel 464 | | | | 465 +-----------+ +---------+ +-----------+ 466 | Endpoint | DTLS | MDD | DTLS | Endpoint | 467 | KEK |<--------| |-------->| KEK | 468 | HBH Key(j)| to KMF | HBH Keys| to KMF | HBH Key(j)| 469 +-----------+ +---------+ +-----------+ 471 Figure 3: Exchanging Key Information Between Entities 473 Endpoints will establish a DTLS-SRTP association over the RTP 474 session's media ports for the purposes of key information exchange 475 with the KMF. The MDD will not terminate the DTLS signaling, but 476 will instead forward DTLS packets received from an endpoint on to the 477 KMF (and vice versa) via a tunnel established between MDD and the 478 KMF. This tunnel used to encapsulate the DTLS-SRTP signaling between 479 the KMF and endpoints will also be used to convey HBH key information 480 from the KMF to the MDD, so no additional protocol or interface is 481 required. 483 4.5.2. Key Exchange during a Conference 485 Following the initial key information exchange with the KMF, 486 endpoints will be able to encrypt media end-to-end with their E2E 487 Key(i), sending that E2E Key(i) to other endpoints encrypted with 488 KEK, and will be able to encrypt and authenticate RTP packets using 489 local HBH Key(j). The procedures defined do not allow the MDD to 490 gain access to the KEK information, preventing it from gaining access 491 to any endpoint's E2E key and subsequently decrypting media. 493 The KEK (i.e., EKT Key) may need to change from time-to-time during 494 the life of a conference, such as when a new participant joins or 495 leaves a conference. Dictating if, when or how often a conference is 496 to be re-keyed is outside the scope of this document, but this 497 framework does accommodate re-keying during the life of a conference. 499 When a KMF decides to rekey a conference, it transmits a specific 500 message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to each of 501 the conference participants. The endpoint MUST create a new SRTP 502 master key and prepare to send that key inside a Full EKT Field using 503 the new EKT Key. Since it may take some time for all of the endpoints 504 in conference to finish re-keying, senders MUST delay a short period 505 of time before sending media encrypted with the new master key, but 506 it MUST be prepared to make use of the information from a new inbound 507 EKT Key immediately. See Section 2.2.2 of 508 [I-D.ietf-perc-srtp-ekt-diet]. 510 5. Entity Trust 512 It is important to this solution framework that the entities can 513 trust and validate the authenticity of other entities, especially the 514 KMF and endpoints. The details of this are outside the scope of 515 specification but a few possibilities are discussed in the following 516 sections. The key requirements is that endpoints can verify they are 517 connected to the correct KMF for the conference and the KMF can 518 verify the endpoints are the correct endpoints for the conference. 520 Two possible approaches to solve this are Identity Assertions and 521 Certificate Fingerprints. 523 5.1. Identity Assertions 525 WebRTC Identity assertion (EDITOR NOTE: add I-D reference) can be 526 used to bind the identity of the user of the endpoint to the 527 fingerprint of the DTLS-SRTP certificate used for the call. This 528 certificate is unique for a given call and a conference. This allows 529 the KMF to ensure that only authorized users participate in the 530 conference. Similarly the KMF can create a WeBRTC Identity assertion 531 bound the fingerprint of the unique certificate used by the KMF for 532 this conference so that the endpoint can validate it is talking to 533 the correct KMF. 535 5.2. Certificate Fingerprints in Session Signaling 537 Entities managing session signaling are generally assumed to be 538 untrusted in the PERC framework. However, there are some deployment 539 scenarios where parts of the session signaling may be assumed 540 trustworthy for the purposes of exchanging, in a manner that can be 541 authenticated, the fingerprint of an entity's certificate. 543 As a concrete example, SIP [RFC3261] and SDP [RFC4566] can be used to 544 convey the fingerprint information per [RFC5763]. An endpoint's SIP 545 User Agent would send an INVITE message containing SDP for the media 546 session along with the endpoint's certificate fingerprint, which can 547 be signed using the procedures described in [RFC4474] for the benefit 548 of forwarding the message to other entities. Other entities can now 549 verify the fingerprints match the certificates found in the DTLS-SRTP 550 connections to find the identity of the far end of the DTLS-SRTP 551 connection and check that is the authorized entity. 553 Ultimately, if using session signaling, an endpoint's certificate 554 fingerprint would need to be securely mapped to a user and conveyed 555 to the KMF so that it can check that that user is authorized. 556 Similarly, the KMF's certificate fingerprint can be conveyed to 557 endpoint in a manner that can be authenticated as being an authorized 558 KMF for this conference. 560 6. Attacks on Privacy Enhanced RTP Conferencing 562 This framework, and the individual protocols defined to support it, 563 must take care to not increase the exposure to Denial of Service 564 (DoS) attacks by untrusted or third-party entities and should take 565 measures to mitigate, where possible, more serious DoS attacks from 566 on-path and off-path attackers. 568 The following section enumerates the kind of attacks that will be 569 considered in the development of this framework's solution. 571 6.1. Third Party Attacks 573 On-path attacks are mitigated by HBH integrity protection and 574 encryption. The integrity protection mitigates packet modification 575 and encryption makes selective blocking of packets harder, but not 576 impossible. 578 Off-path attackers may try connecting to different PERC entities and 579 send specifically crafted packets. A successful attacker might be 580 able to get the MDD to forward such packets. If not making use of 581 HBH authentication on the MDD, such an attack could only be detected 582 in the receiving endpoints where the forged packets would finally be 583 dropped. 585 Another potential attack is a third party claiming to be an MDD, 586 fooling endpoints in to sending packets to the false MDD instead of 587 the correct one. The deceived sending endpoints could incorrectly 588 assuming their packets have been delivered to endpoints when they in 589 fact have not. Further, the false MDD may cascade to another 590 legitimate MDD creating a false version of the real conference. 592 This attack can be mitigated by the false MDD not being authenticated 593 by the KMF during PERC Tunnel establishment. Without the tunnel in 594 place, endpoints will not establish secure associations with the KMF 595 and receive the KEK, causing the conference to not proceed. 597 6.2. MDD Attacks 599 The MDD can attack the session in a number of possible ways. 601 6.2.1. Denial of service 603 Any modification of the end-to-end authenticated data will result in 604 the receiving endpoint getting an integrity failure when performing 605 authentication on the received packet. 607 The MDD can also attempt to perform resource consumption attacks on 608 the receiving endpoint. One such attack would be to insert random 609 SSRC/CSRC values in any RTP packet with an inband key-distribution 610 message attached (i.e., Full EKT Field). Since such a message would 611 trigger the receiver to form a new cryptographic context, the MDD can 612 attempt to consume the receiving endpoints resources. 614 Another denial of service attack is where the MDD rewrites the PT 615 field to indicate a different codec. The effect of this attack is 616 that any payload packetized and encoded according to one RTP payload 617 format is then processed using another payload format and codec. 618 Assuming that the implementation is robust to random input, it is 619 unlikely to cause crashes in the receiving software/hardware. 620 However, it is not unlikely that such rewriting will cause severe 621 media degradation. 623 For audio formats, this attack is likely to cause highly disturbing 624 audio and/or can be damaging to hearing and playout equipment. 626 6.2.2. Replay Attack 628 Replay attack is when an already received packets from a previous 629 point in the RTP stream is replayed as new packet. This could, for 630 example, allow an MDD to transmit a sequence of packets identified as 631 a user saying "yes", instead of the "no" the user actually said. 633 The mitigation for a replay attack is to prevent old packets beyond a 634 small-to-modest jitter and network re-ordering sized window to be 635 rejected. End-to-end replay protection MUST be provided for the 636 whole duration of the conference. 638 6.2.3. Delayed Playout Attack 640 The delayed playout attack is a variant of the replay attack. This 641 attack is possible even if E2E replay protection is in place. 642 However, due to fact that the MDD is allowed to select a sub-set of 643 streams and not forward the rest to a receiver, such as in forwarding 644 only the most active speakers, the receiver has to accept gaps in the 645 E2E packet sequence. The issue with this is that an MDD can select 646 to not deliver a particular stream for a while. 648 Within the window from last packet forwarded to the receiver and the 649 latest received by the MDD, the MDD can select an arbitrary starting 650 point when resuming forwarding packets. Thus what the media source 651 said can be substantially delayed at the receiver with the receiver 652 believing that it is what was said just now, and only delayed due to 653 transport delay. 655 6.2.4. Splicing Attack 657 The splicing attack is an attack where an MDD receiving multiple 658 media sources splices one media stream into the other. If the MDD is 659 able to change the SSRC without the receiver having any method for 660 verifying the original source ID, then the MDD could first deliver 661 stream A and then later forward stream B under the same SSRC as 662 stream A was previously using. Not allowing the MDD to change the 663 SSRC mitigates this attack. 665 7. To-Do List 667 o The mapping of endpoints-to-conference identifiers may need to be 668 conveyed in the framework. Need Revisit this text after a design 669 choice is made between alternatives. 671 o Consider adding a list of RTP header extensions that should/must 672 not be E2E encrypted. 674 o Endpoints, KMF and MDD provider must securely convey their 675 respective certificate information directly or indirectly via some 676 means, such as via an identity service provider. 678 o If as in "Double" draft, the ROC value is no longer in the clear 679 and associated with the "outer" protection scheme, we may need to 680 require that the MDD maintain a separate ROC value for each SSRC 681 sent to each endpoint. This ROC value should start at 0 682 regardless of the sequence number in that first packet sent to an 683 endpoint. 685 o Investigate adding ability to enable the transmission of one-way 686 media from a non-trusted device (e.g., announcements). One 687 possible solution is to have the KMF send an "ekt_key" message 688 that is explicitly labeled for receive-only and giving that to 689 announcement servers. A possible approach would be to define EKT 690 Keys with a SPI > 32000, for example, for this purpose and 691 endpoints should only use those EKT Keys to decrypt Full EKT 692 Fields received from such transmitters. Endpoints would never 693 send media with EKT Keys with those SPI values. 695 8. IANA Considerations 697 There are no IANA considerations for this document. 699 9. Security Considerations 701 [TBD] 703 10. Acknowledgments 705 The authors would like to thank Mo Zanaty and Christian Oien for 706 invaluable input on this document. Also, we would like to 707 acknowledge Nermeen Ismail for serving on the initial versions of 708 this document as a co-author. 710 11. References 712 11.1. Normative References 714 [I-D.ietf-perc-double] 715 Jennings, C., Jones, P., and A. Roach, "SRTP Double 716 Encryption Procedures", draft-ietf-perc-double-00 (work in 717 progress), May 2016. 719 [I-D.ietf-perc-srtp-ekt-diet] 720 Mattsson, J., McGrew, D., Wing, D., and C. Jennings, 721 "Encrypted Key Transport for Secure RTP", draft-ietf-perc- 722 srtp-ekt-diet-00 (work in progress), May 2016. 724 [I-D.jones-perc-dtls-tunnel] 725 Jones, P., "DTLS Tunnel between Media Distribution Device 726 and Key Management Function to Facilitate Key Exchange", 727 draft-jones-perc-dtls-tunnel-02 (work in progress), March 728 2016. 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 732 RFC2119, March 1997, 733 . 735 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 736 Jacobson, "RTP: A Transport Protocol for Real-Time 737 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 738 July 2003, . 740 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 741 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 742 RFC 3711, DOI 10.17487/RFC3711, March 2004, 743 . 745 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 746 Security (DTLS) Extension to Establish Keys for the Secure 747 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 748 10.17487/RFC5764, May 2010, 749 . 751 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 752 Real-time Transport Protocol (SRTP)", RFC 6904, DOI 753 10.17487/RFC6904, April 2013, 754 . 756 11.2. Informative References 758 [I-D.ietf-avtcore-rtp-topologies-update] 759 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 760 ietf-avtcore-rtp-topologies-update-10 (work in progress), 761 July 2015. 763 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 764 A., Peterson, J., Sparks, R., Handley, M., and E. 765 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 766 DOI 10.17487/RFC3261, June 2002, 767 . 769 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 770 Authenticated Identity Management in the Session 771 Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/ 772 RFC4474, August 2006, 773 . 775 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 776 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 777 July 2006, . 779 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 780 for Establishing a Secure Real-time Transport Protocol 781 (SRTP) Security Context Using Datagram Transport Layer 782 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 783 2010, . 785 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 786 Transport Protocol (RTP) Header Extension for Client-to- 787 Mixer Audio Level Indication", RFC 6464, DOI 10.17487/ 788 RFC6464, December 2011, 789 . 791 Authors' Addresses 793 Paul Jones 794 Cisco 795 7025 Kit Creek Rd. 796 Research Triangle Park, North Carolina 27709 797 USA 799 Phone: +1 919 476 2048 800 Email: paulej@packetizer.com 801 David Benham 802 Cisco 803 170 West Tasman Drive 804 San Jose, California 95134 805 USA 807 Email: dbenham@cisco.com