idnits 2.17.1 draft-jones-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 (March 21, 2016) is 2957 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 702, but not defined -- No information found for draft-jennings-perc-srtp-ekt-diet - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.jennings-perc-srtp-ekt-diet' == 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 (~~), 3 warnings (==), 5 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: September 22, 2016 March 21, 2016 7 A Solution Framework for Private Media in Privacy Enhanced RTP 8 Conferencing 9 draft-jones-perc-private-media-framework-02 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 September 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 12 73 5.2. Certificate Fingerprints in Session Signaling . . . . . . 12 74 6. Attacks on Privacy Enhanced RTP Conferencing . . . . . . . . 13 75 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 13 76 6.2. MDD Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 14 78 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 14 79 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 14 80 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 15 81 7. To-Do List . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 7.1. What is Needed to Realize this Framework . . . . . . . . 15 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 11.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 distribution device (MDD), as might be the case with a traditional 99 media server or multipoint control unit (MCU). Instead, media flows 100 transmitted by conference participants are simply forwarded by the 101 MDD to each of the other participants, often forwarding only a subset 102 of flows based on voice activity detection or other criteria. In 103 some instances, the switching MDDs 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 MDDs can be deployed on 108 general-purpose computing hardware. This, in turn, means that it is 109 possible to deploy switching MDDs in virtualized environments, 110 including private and public clouds. Deploying conference resources 111 in a cloud environment might introduce a higher security risk. 112 Whereas traditional conference resources were usually deployed in 113 private networks that were protected, cloud-based conference 114 resources might be viewed as less secure since they are not always 115 physically controlled by those who use the hardware. Additionally, 116 there are usually several ports open to the public in cloud 117 deployments, such as for remote administration, and so on. 119 This document defines a solution framework wherein privacy is ensured 120 by making it impossible for an MDD to gain access to keys needed to 121 decrypt or authenticate the actual media content sent between 122 conference participants. At the same time, the framework allows for 123 the switching MDD to modify certain RTP headers; add, remove, 124 encrypt, or decrypt RTP header extensions; and encrypt and decrypt 125 RTCP packets. The framework also prevents replay attacks by 126 authenticating each packet transmitted between a given participant 127 and the switching MDD by using a key that is independent from the 128 media encryption and authentication key(s) and is unique to the 129 participating endpoint and the switching MDD. 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 E2E (End-to-End): Communications from one endpoint through one or 147 more MDDs to the endpoint at the other end. 149 HBH (Hop-by-Hop): Communications between an endpoint and an MDD or 150 between MDDs. 152 Endpoint: An RTP flow terminating entity that has possession of E2E 153 media encryption keys and terminates end-to-end (E2E) encryption. 154 This may 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 MDD (Media Distribution Device): An RTP middlebox that is not allowed 159 to to have access to E2E encryption keys. It may operate according 160 to any of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] 161 per the constraints defined by the PERC system, which includes, but 162 not limited to, having no access to RTP media unencrypted and having 163 limits on what RTP header field it can alter. 165 KMF (Key Management Function): An entity that is a logical function 166 which passes keying material and related information to endpoints and 167 MDDs that is appropriate for each. The KMF might be co-resident with 168 another entity trusted with E2E keying material. 170 Conference: Two or more participants communicating via trusted 171 endpoints to exchange RTP flows through one or more MDDs. 173 Third Party: Any entity that is not an Endpoint, MDD, KMF or Call 174 Processing entity as described in this document. 176 3. PERC Entities and Trust Model 178 The following figure depicts the trust relationships, direct or 179 indirect, between entities described in the subsequent sub-sections. 180 Note that these entities may be co-located or further divided into 181 multiple, separate physical devices. 183 Please note that some entities classified as untrusted in the simple, 184 general deployment scenario used most commonly in this document might 185 be considered trusted in other deployments. This document does not 186 preclude such scenarios, but will keep the definitions and examples 187 focused by only using the the simple, most general deployment 188 scenario. 190 | 191 +----------+ | +-----------------+ 192 | Endpoint | | | Call Processing | 193 +----------+ | +-----------------+ 194 | 195 | 196 +----------------+ | +--------------------+ 197 | Key Management | | | Media Distribution | 198 | Function | | | Device | 199 +----------------+ | +--------------------+ 200 | 201 Trusted | Untrusted 202 Entities | Entities 203 | 205 Figure 1: Trusted and Untrusted Entities in PERC 207 3.1. Untrusted Entities 209 The architecture described in this framework document enables 210 conferencing infrastructure to be hosted in domains, such as in a 211 cloud conferencing provider's facilities, where the trustworthiness 212 is below the level needed to assume the privacy of participant's 213 media will not be compromised. The conferencing infrastructure in 214 such a domain is still trusted with reliably connecting the 215 participants together in a conference, but not trusted with keying 216 material needed to decrypt any of the participant's media. Entities 217 in such lower trustworthiness domains will simply be referred to as 218 untrusted entities from this point forward. This does not mean that 219 they are completely untrusted as they may be trusted with most non- 220 media related aspects of hosting a conference. 222 3.1.1. MDD 224 An MDD forwards RTP flows between endpoints in the conference while 225 performing per-hop authentication of each RTP packet. The MDD may 226 need access to one or more RTP headers or header extensions, 227 potentially adding or modifying a certain subset. The MDD will also 228 relay secured messaging between the endpoints and the key management 229 function and will acquire per-hop key information from the KMF. The 230 actual media content MUST NOT not be decryptable by an MDD, so it is 231 untrusted to have access to the E2E media encryption keys, which this 232 framework's key exchange mechanisms will prevent. 234 An endpoint's ability to join a conference hosted by an MDD MUST NOT 235 alone be interpreted as being authorized to have access to the E2E 236 media encryption keys, as the MDD does not have the ability to 237 determine whether an endpoint is authorized. 239 An MDD MUST perform its role in properly forwarding media packets 240 while taking measures to mitigate the adverse effects of denial of 241 service attacks (refer to Section Section 6), etc, to a level equal 242 to or better than traditional conferencing (i.e. pre-PERC) 243 deployments. 245 An MDD or associated conferencing infrastructure may also initiate or 246 terminate various conference control related messaging, which is 247 outside the scope of this framework document. 249 3.1.2. Call Processing 251 The call processing function is untrusted in the simple, general 252 deployment scenario. When a physical subset of the call processing 253 function resides in facilities outside the trusted domain, it should 254 not be trusted to have access to E2E key information. 256 The call processing function may include the processing of call 257 signaling messages, as well as the signing of those messages. It may 258 also authenticate the endpoints for the purpose of call signaling and 259 subsequently joining of a conference hosted through one or more MDDs. 260 Call processing may optionally ensure the privacy of call signaling 261 messages between itself, the endpoint, and other entities. 263 In any deployment scenario where the call processing function is 264 considered trusted, the call processing function MUST ensure the 265 integrity of received messages before forwarding to other entities. 267 3.2. Trusted Entities 269 From the PERC model system perspective, entities considered trusted 270 (refer to Figure 1) can be in possession of the E2E media encryption 271 key(s) for one or more conferences. 273 3.2.1. Endpoint 275 An endpoint is considered trusted and will have access to E2E key 276 information. While it is possible for an endpoint to be compromised, 277 subsequently performing in undesired ways, defining endpoint 278 resistance to compromise is outside the scope of this document. 279 Endpoints will take measures to mitigate the adverse effects of 280 denial of service attacks (refer to Section 6) from other entities, 281 including from other endpoints, to a level equal to or better than 282 traditional conference (i.e., pre-PERC) deployments. 284 3.2.2. KMF 286 The KMF, which may be collocated with an endpoint or exist 287 standalone, is responsible for providing key information to endpoints 288 for both end-to-end and hop-by-hop security and for providing key 289 information to MDDs for the hop-by-hop security. 291 Interaction between the KMF and the call processing function may be 292 necessary to for proper conference-to-endpoint mappings, which may or 293 may not be satisfied by getting information directly from the 294 endpoints or via some other means. [TO DO: Revisit this text after 295 design choice(s) are made between the alternatives.] 297 Obviously, the KMF needs to be closely managed to prevent 298 exploitation by an adversary, as any kind of security compromise of 299 the KMF puts the security of the conference at risk. 301 4. Framework for PERC 303 The purpose for this framework is to define a means through which 304 media privacy can be ensured when communicating within a conferencing 305 environment consisting of one or more MDDs that only switch, hence 306 not terminate, media. It does not otherwise attempt to hide the fact 307 that a conference between endpoints is taking place. 309 This framework reuses several specified RTP security technologies, 310 including SRTP [RFC3711], PERC EKT [I-D.jennings-perc-srtp-ekt-diet], 311 and DTLS-SRTP [RFC5764]. 313 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 315 This solution framework focuses on the end-to-end privacy and 316 integrity of the participant's media by limiting access to end-to-end 317 key information to trusted entities. However, this framework does 318 give an MDD access to RTP headers and all or most header extensions, 319 as well as the ability to modify a certain subset of those headers 320 and to add header extensions. Packets received by an MDD or an 321 endpoint are authenticated hop-by-hop. 323 To enable all of the above, this framework defines the use of two 324 security contexts and two associated encryption keys; an "inner" key 325 (E2E Key(i); i={a given endpoint}) for authenticated encryption of 326 RTP media between endpoints and an "outer" key (HBH Key(j); j={a 327 given hop}) for the hop between an endpoint and an MDD or between 328 MDDs. Reference the following figure. 330 +--------+ HBH +-----+ HBH +-----+ HBH +--------+ 331 | |=============| |=========| |=============| | 332 |Endpoint|-E2E Key(A)->| MDD |-------->| MDD |------------>|Endpoint| 333 | A |<------------| X |<--------| Y |<-E2E Key(B)-| B | 334 | |=============| |=========| |=============| | 335 +--------+ Key(AX) +-----+ Key(XY) +-----+ Key(YB) +--------+ 337 E2E and HBH Keys Used for Authenticated Encryption 339 The PERC Double draft specification [I-D.jennings-perc-double] uses 340 standard SRTP keying material and recommended cryptographic 341 transform(s) to first form the inner, end-to-end SRTP cryptographic 342 context. That end-to-end SRTP cryptographic context MAY be used to 343 encrypt some RTP header extensions along with RTP media content. The 344 output of this is treated like an RTP packet and encrypted again 345 using the outer hop-by-hop cryptographic context. The endpoint 346 executes the entire Double operation while the MDD just performs the 347 outer, hop-by-hop operation. 349 RTCP can only be encrypted hop-by-hop, not end-to-end. This 350 framework introduces no additional step for RTCP authenticated 351 encryption, so the procedures needed are specified in [RFC3711] and 352 use the same outer, hop-by-hop cryptographic context chosen in the 353 Double operation described above. 355 4.2. E2E Key Confidentiality 357 To ensure the confidentiality of E2E keys shared between endpoints, 358 endpoints will make use of a common Key Encryption Key (KEK) that is 359 known only by the trusted entities in a conference. That KEK, 360 defined in the PERC EKT [I-D.jennings-perc-srtp-ekt-diet] as the EKT 361 Key, will be used to subsequently encrypt SRTP master keys used for 362 E2E authenticated encryption (E2E Key(i); i={a given endpoint}) of 363 media sent by a given endpoint. 365 +---------------------+------------+-------+-------+------------+ 366 | Key / Entity | Endpoint A | MDD X | MDD Y | Endpoint B | 367 +---------------------+------------+---------------+------------+ 368 | KEK | Yes | No | No | Yes | 369 +---------------------+------------+---------------+------------+ 370 | E2E Key (i) | Yes | No | No | Yes | 371 +---------------------+------------+---------------+------------+ 372 | HBH Key (A<=>MDD X) | Yes | Yes | No | No | 373 +---------------------+------------+---------------+------------+ 374 | HBH Key (B<=>MDD Y) | No | No | Yes | Yes | 375 +---------------------+------------+---------------+------------+ 377 Figure 2: Keys per Entity 379 4.3. E2E Keys and Endpoint Operations 381 Any given RTP media flow can be identified by its SSRC, and endpoints 382 might send more than one at a time and change the mix of media flows 383 transmitted during the life of a conference. 385 Thus, endpoints MUST maintain a list of SSRCs from received RTP flows 386 and each SSRC's associated E2E Key(i) information. Following a 387 change of the KEK (i.e., EKT Key), prior E2E Key(i) information 388 SHOULD be retained just long enough to ensure that late-arriving or 389 out-of-order packets can be successfully decrypted and rendered. 390 [NOTE: Perhaps a separate best practices document can recommend 391 durations after some real world testing?] The endpoint SHOULD 392 discard the E2E Key(i) and KEK information when it leaves the 393 conference. 395 If there is a need to encrypt one or more RTP header extensions end- 396 to-end, an encryption key is derived from the end-to-end SRTP master 397 key to encrypt header extensions as per [RFC6904]. The MDD will not 398 be able use the information contained in those header extensions with 399 E2E encryption. [TO DO: Add a list to this doc of RTP Header 400 Extensions that are off limits to - the MUST NOTs - be E2E 401 encrypted.] 403 4.4. HBH Keys and Hop Operations 405 To ensure the integrity of transmitted media packets, this framework 406 requires that every packet be authenticated hop-by-hop (HBH) between 407 an endpoint and an MDD, as well between MDDs. The authentication key 408 used for hop-by-hop authentication is derived from an SRTP master key 409 shared only on the respective hop (HBH Key(j); j={a given hop}). 410 Each HBH Key(j) is distinct per hop and no two hops ever 411 intentionally use the same SRTP master key. 413 Using hop-by-hop authentication gives the MDD the ability to change 414 certain RTP header values. Which values the MDD can change in the 415 RTP header are defined in [I-D.jennings-perc-double]. RTCP can only 416 be encrtpted, giving the MDD the flexibility to forward RTCP content 417 unchanged, transmit compound RTCP packets or to initiate RTCP packets 418 for reporting statistics or conveying other information. Performing 419 hop-by-hop authentication for all RTP and RTCP packets also helps 420 provide replay protection (see Section 6). 422 If there is a need to encrypt one or more RTP header extensions hop- 423 by-hop, an encryption key is derived from the hop-by-hop SRTP master 424 key to encrypt header extensions as per [RFC6904]. This will still 425 give the switching MDD visibility into header extensions, such as the 426 one used to determine audio level [RFC6464] of conference 427 participants. Note that when RTP header extensions are encrypted, 428 all hops - in the untrusted domain at least - will need to decrypt 429 and re-encrypt these encrypted header extensions. 431 4.5. Key Exchange 433 To facilitate key exchange required to establish or generate an E2E 434 key and a HBH key for an endpoint and the same HBH key for the MDD, 435 this framework utilizes a DTLS-SRTP [RFC5764] association between an 436 endpoint and the KMF. To establish this association, an endpoint 437 will send DTLS-SRTP messages to the MDD which will then forward them 438 to the MDD as defined in DTLS Tunnel for PERC 439 [I-D.jones-perc-dtls-tunnel]. The KEK (i.e., EKT Key) is also 440 conveyed by the KMF over the DTLS association to endpoints via 441 procedures defined in PERC EKT [I-D.jennings-perc-srtp-ekt-diet]. 443 MDDs use DTLS-SRTP [RFC5764] directly with a peer MDD to establish 444 HBH keys for transmitting RTP and RTCP packets that peer MDD. The 445 KMF does not facilitate establishing HBH keys for use between MDDs. 447 4.5.1. Initial Key Exchange and KMF 449 The procedures defined in DTLS Tunnel for PERC 450 [I-D.jones-perc-dtls-tunnel] establish one or more DTLS tunnels 451 between the MDD and KMF, making it is possible for the MDD to 452 facilitate the establishment of a secure DTLS association between 453 each endpoint and the KMF as shown the following figure. The DTLS 454 association between endpoints and the KMF will enable each endpoint 455 to receive E2E key information, Key Encryption Key (KEK) information 456 (i.e., EKT Key), and HBH key information. At the same time, the KMF 457 can securely provide the HBH key information to the MDD. The key 458 information summarized here may include the SRTP master key, SRTP 459 master salt, and the negotiated cryptographic transform. 461 KEK info +---------+ HBH Key info 462 to endpoints | KMF | to endpoints & MDD 463 +---------+ 464 | ^ ^ | 465 | | | |-DTLS Tunnel 466 | | | | 467 +-----------+ +---------+ +-----------+ 468 | Endpoint | DTLS | MDD | DTLS | Endpoint | 469 | KEK |<--------| |-------->| KEK | 470 | HBH Key(j)| to KMF | HBH Keys| to KMF | HBH Key(j)| 471 +-----------+ +---------+ +-----------+ 473 Figure 3: Exchanging Key Information Between Entities 475 Endpoints will establish a DTLS-SRTP association over the RTP 476 session's media ports for the purposes of key information exchange 477 with the KMF. The MDD will not terminate the DTLS signaling, but 478 will instead forward DTLS packets received from an endpoint on to the 479 KMF (and vice versa) via a tunnel established between MDD and the 480 KMF. This tunnel used to encapsulate the DTLS-SRTP signaling between 481 the KMF and endpoints will also be used to convey HBH key information 482 from the KMF to the MDD, so no additional protocol or interface is 483 required. 485 4.5.2. Key Exchange during a Conference 487 Following the initial key information exchange with the KMF, 488 endpoints will be able to encrypt media end-to-end with their E2E 489 Key(i), sending that E2E Key(i) to other endpoints encrypted with 490 KEK, and will be able to encrypt and authenticate RTP packets using 491 local HBH Key(j). The procedures defined do not allow the MDD to 492 gain access to the KEK information, preventing it from gaining access 493 to any endpoint's E2E key and subsequently decrypting media. 495 The KEK (i.e., EKT Key) may need to change from time-to-time during 496 the life of a conference, such as when a new participant joins or 497 leaves a conference. Dictating if, when or how often a conference is 498 to be re-keyed is outside the scope of this document, but this 499 framework does accommodate re-keying during the life of a conference. 501 When a KMF decides to rekey a conference, it transmits a specific 502 message defined in PERC EKT [I-D.jennings-perc-srtp-ekt-diet] to each 503 of the conference participants. The endpoint MUST create a new SRTP 504 master key and prepare to send that key inside a Full EKT Field using 505 the new EKT Key. Since it may take some time for all of the endpoints 506 in conference to finish re-keying, senders SHOULD delay a short 507 period of time before sending media encrypted with the new master 508 key, but it MUST be prepared to make use of the information from a 509 new inbound EKT Key immediately. [TO DO: Either need to pick a short 510 delay period for endpoints to use per above, defer to a future best 511 practices document or consider having the KMF manage the delay period 512 given it knows the size of a given conference.] 514 5. Entity Trust 516 It is important to this solution framework that the entities can 517 trust and validate the authenticity of other entities, especially the 518 KMF and endpoints. The details of this are outside the scope of 519 specification but a few possibilities are discussed in the following 520 sections. The key requirements is that endpoints can verify they are 521 connected to the correct KMF for the conference and the KMF can 522 verify the endpoints are the correct endpoints for the conference. 524 Two possible approaches to solve this are Identity Assertions and 525 Certificate Fingerprints. 527 5.1. Identity Assertions 529 WebRTC (EDIT: add reference) Identity assertion can be used to bind 530 the identity of the user of the endpoint to the fingerprint of the 531 DTLS-SRTP certificate used for the call. This certificate is unique 532 for a given call and a conference. This allows the KMF to ensure 533 that only authorized users participate in the conference. Similarly 534 the KMF can create a WeBRTC Identity assertion bound the fingerprint 535 of the unique certificate used by the KMF for this conference so that 536 the endpoint can validate it is talking to the correct KMF. 538 5.2. Certificate Fingerprints in Session Signaling 540 Entities managing session signaling are generally assumed to be 541 untrusted in the PERC framework. However, there are some deployment 542 scenarios where parts of the session signaling may be assumed 543 trustworthy for the purposes of exchanging, in a manner that can be 544 authenticated, the fingerprint of an entity's certificate. 546 As a concrete example, SIP [RFC3261] and SDP [RFC4566] can be used to 547 convey the fingerprint information per [RFC5763]. An endpoint's SIP 548 User Agent would send an INVITE message containing SDP for the media 549 session along with the endpoint's certificate fingerprint, which can 550 be signed using the procedures described in [RFC4474] for the benefit 551 of forwarding the message to other entities. Other entities can now 552 verify the fingerprints match the certificates found in the DTLS-SRTP 553 connections to find the identity of the far end of the DTLS-SRTP 554 connection and check that is the authorized entity. 556 Ultimately, if using session signaling, an endpoint's certificate 557 fingerprint would need to be securely mapped to a user and conveyed 558 to the KMF so that it can check that that user is authorized. 559 Similarly, the KMF's certificate fingerprint can be conveyed to 560 endpoint in a manner that can be authenticated as being an authorized 561 KMF for this conference. 563 6. Attacks on Privacy Enhanced RTP Conferencing 565 This framework, and the individual protocols defined to support it, 566 must take care to not increase the exposure to Denial of Service 567 (DoS) attacks by untrusted or third-party entities and should take 568 measures to mitigate, where possible, more serious DoS attacks from 569 on-path and off-path attackers. 571 The following section enumerates the kind of attacks that will be 572 considered in the development of this framework's solution. 574 6.1. Third Party Attacks 576 On-path attacks are mitigated by HBH integrity protection and 577 encryption. The integrity protection mitigates packet modification 578 and encryption makes selective blocking of packets harder, but not 579 impossible. 581 Off-path attackers may try connecting to different PERC entities and 582 send specifically crafted packets. A successful attacker might be 583 able to get the MDD to forward such packets. If not making use of 584 HBH authentication on the MDD, such an attack could only be detected 585 in the receiving endpoints where the forged packets would finally be 586 dropped. 588 Another potential attack is a third party claiming to be an MDD, 589 fooling endpoints in to sending packets to the false MDD instead of 590 the correct one. The deceived sending endpoints could incorrectly 591 assuming their packets have been delivered to endpoints when they in 592 fact have not. Further, the false MDD may cascade to another 593 legitimate MDD creating a false version of the real conference. This 594 attack is mitigated since false MDD would not be authenicated by the 595 KMF and be able tunnel the DTLS-SRTP signaling to/from the KMF. 596 Since it cannot tunnel the DTLS-SRTP signaling, endpoints will not 597 get the KEK and the conference will not go on. [TO DO: Include the 598 exchange valid MDD certficates with the KMF in this doc or not?] 600 6.2. MDD Attacks 602 The MDD can attack the session in a number of possible ways. 604 6.2.1. Denial of service 606 Any modification of the end-to-end authenticated data will result in 607 the receiving endpoint getting an integrity failure when performing 608 authentication on the received packet. 610 The MDD can also attempt to perform resource consumption attacks on 611 the receiving endpoint. One such attack would be to insert random 612 SSRC/CSRC values in any RTP packet with an inband key-distribution 613 message attached (i.e., Full EKT Field). Since such a message would 614 trigger the receiver to form a new cryptographic context, the MDD can 615 attempt to consume the receiving endpoints resources. 617 Another denial of service attack is where the MDD rewrites the PT 618 field to indicate a different codec. The effect of this attack is 619 that any payload packetized and encoded according to one RTP payload 620 format is then processed using another payload format and codec. 621 Assuming that the implementation is robust to random input, it is 622 unlikely to cause crashes in the receiving software/hardware. 623 However, it is not unlikely that such rewriting will cause severe 624 media degradation. 626 For audio formats, this attack is likely to cause highly disturbing 627 audio and/or can be damaging to hearing and playout equipment. 629 6.2.2. Replay Attack 631 Replay attack is when an already received packets from a previous 632 point in the RTP stream is replayed as new packet. This could, for 633 example, allow an MDD to transmit a sequence of packets identified as 634 a user saying "yes", instead of the "no" the user actually said. 636 The mitigation for a replay attack is to prevent old packets beyond a 637 small-to-modest jitter and network re-ordering sized window to be 638 rejected. End-to-end replay protection MUST be provided for the 639 whole duration of the conference. 641 6.2.3. Delayed Playout Attack 643 The delayed playout attack is a variant of the replay attack. This 644 attack is possible even if E2E replay protection is in place. 645 However, due to fact that the MDD is allowed to select a sub-set of 646 streams and not forward the rest to a receiver, such as in forwarding 647 only the most active speakers, the receiver has to accept gaps in the 648 E2E packet sequence. The issue with this is that an MDD can select 649 to not deliver a particular stream for a while. 651 Within the window from last packet forwarded to the receiver and the 652 latest received by the MDD, the MDD can select an arbitrary starting 653 point when resuming forwarding packets. Thus what the media source 654 said can be substantially delayed at the receiver with the receiver 655 believing that it is what was said just now, and only delayed due to 656 transport delay. 658 6.2.4. Splicing Attack 660 The splicing attack is an attack where an MDD receiving multiple 661 media sources splices one media stream into the other. If the MDD is 662 able to change the SSRC without the receiver having any method for 663 verifying the original source ID, then the MDD could first deliver 664 stream A and then later forward stream B under the same SSRC as 665 stream A was previously using. Not allowing the MDD to change the 666 SSRC mitigates this attack. 668 7. To-Do List 670 7.1. What is Needed to Realize this Framework 672 o Endpoints and KMF must securely convey their respective 673 certificate information directly or indirectly via some other 674 means or identity service provider. 676 o If as in "Double" draft, the ROC value is no longer in the clear 677 and associated with the "outer" protection scheme, we may need to 678 require that the MDD maintain a separate ROC value for each SSRC 679 sent to each separate endpoint. This ROC value should start at 0 680 regardless of the sequence number in that first packet sent to an 681 endpoint. [EDIT: Do we document this in this framework or in 682 Double draft?] 684 o Investigate adding ability to enable the transmission of one-way 685 media from a non-trusted device (e.g., announcements). One 686 possible solution is to have the KMF send an "ekt_key" message 687 that is explicitly labeled for receive-only and giving that to 688 announcement servers. As opposed to modifying the EKT spec for 689 this PERC-specific need, we could say in the framework that EKT 690 Keys with a SPI > 32000, say, are intended for this purpose and 691 trusted endpoints should only use those EKT Keys to decrypt Full 692 EKT Fields received from such transmitters. Thus, trusted 693 endpoints would never send media with EKT Keys having those SPI 694 values. 696 8. IANA Considerations 698 There are no IANA considerations for this document. 700 9. Security Considerations 702 [TBD] 704 10. Acknowledgments 706 The authors would like to thank Mo Zanaty and Christian Oien for 707 invaluable input on this document. Also, we would like to 708 acknowledge Nermeen Ismail for serving on the initial versions of 709 this document as a co-author. 711 11. References 713 11.1. Normative References 715 [I-D.jennings-perc-double] 716 Jennings, C., Jones, P., and A. Roach, "SRTP Double 717 Encryption Procedures", draft-jennings-perc-double-01 718 (work in progress), March 2016. 720 [I-D.jennings-perc-srtp-ekt-diet] 721 Mattsson, J., McGrew, D., Wing, D., Andreasen, F., and C. 722 Jennings, "Encrypted Key Transport for Secure RTP", March 723 2016. 725 [I-D.jones-perc-dtls-tunnel] 726 Jones, P., "DTLS Tunnel between Media Distribution Device 727 and Key Management Function to Facilitate Key Exchange", 728 draft-jones-perc-dtls-tunnel-02 (work in progress), 729 March 2016. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 733 RFC2119, March 1997, 734 . 736 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 737 Jacobson, "RTP: A Transport Protocol for Real-Time 738 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 739 July 2003, . 741 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 742 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 743 RFC 3711, DOI 10.17487/RFC3711, March 2004, 744 . 746 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 747 Security (DTLS) Extension to Establish Keys for the Secure 748 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 749 10.17487/RFC5764, May 2010, 750 . 752 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 753 Real-time Transport Protocol (SRTP)", RFC 6904, DOI 754 10.17487/RFC6904, April 2013, 755 . 757 11.2. Informative References 759 [I-D.ietf-avtcore-rtp-topologies-update] 760 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 761 ietf-avtcore-rtp-topologies-update-10 (work in progress), 762 July 2015. 764 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 765 A., Peterson, J., Sparks, R., Handley, M., and E. 766 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 767 DOI 10.17487/RFC3261, June 2002, 768 . 770 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 771 Authenticated Identity Management in the Session 772 Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/ 773 RFC4474, August 2006, 774 . 776 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 777 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 778 July 2006, . 780 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 781 for Establishing a Secure Real-time Transport Protocol 782 (SRTP) Security Context Using Datagram Transport Layer 783 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 784 2010, . 786 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 787 Transport Protocol (RTP) Header Extension for Client-to- 788 Mixer Audio Level Indication", RFC 6464, DOI 10.17487/ 789 RFC6464, December 2011, 790 . 792 Authors' Addresses 794 Paul Jones 795 Cisco 796 7025 Kit Creek Rd. 797 Research Triangle Park, North Carolina 27709 798 USA 800 Phone: +1 919 476 2048 801 Email: paulej@packetizer.com 803 David Benham 804 Cisco 805 170 West Tasman Drive 806 San Jose, California 95134 807 USA 809 Email: dbenham@cisco.com