idnits 2.17.1 draft-ietf-perc-private-media-framework-06.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 5, 2018) is 2237 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-08 == Outdated reference: A later version (-12) exists of draft-ietf-perc-dtls-tunnel-02 ** Downref: Normative reference to an Informational draft: draft-ietf-perc-dtls-tunnel (ref. 'I-D.ietf-perc-dtls-tunnel') == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-07 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-13 -- 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: 1 error (**), 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: September 6, 2018 C. Groves 6 Independent 7 March 5, 2018 9 A Solution Framework for Private Media in Privacy Enhanced RTP 10 Conferencing 11 draft-ietf-perc-private-media-framework-06 13 Abstract 15 This document describes a solution framework for ensuring that media 16 confidentiality and integrity are maintained end-to-end within the 17 context of a switched conferencing environment where media 18 distributors are not trusted with the end-to-end media encryption 19 keys. The solution aims to build upon existing security mechanisms 20 defined for the real-time transport protocol (RTP). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 6, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 5 59 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 6 61 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6 62 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7 63 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7 65 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 8 67 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 9 68 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9 69 4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 10 70 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 11 72 4.5.2. Key Exchange during a Conference . . . . . . . . . . 12 73 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 13 75 5.2. Certificate Fingerprints in Session Signaling . . . . . . 13 76 5.3. Conferences Identification . . . . . . . . . . . . . . . 14 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14 79 6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 15 80 6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 15 81 6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 16 82 6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 16 83 6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 16 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 9.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Appendix A. PERC Key Inventory . . . . . . . . . . . . . . . . . 19 90 A.1. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 20 91 A.2. The Key Distributor Transmits the KEK (EKT Key) . . . . . 20 92 A.3. Endpoints fabricate an SRTP Master Key . . . . . . . . . 21 93 A.4. Who has What Key . . . . . . . . . . . . . . . . . . . . 21 94 Appendix B. PERC Packet Format . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 Switched conferencing is an increasingly popular model for multimedia 100 conferences with multiple participants using a combination of audio, 101 video, text, and other media types. With this model, real-time media 102 flows from conference participants are not mixed, transcoded, 103 transrated, recomposed, or otherwise manipulated by a Media 104 Distributor, as might be the case with a traditional media server or 105 multipoint control unit (MCU). Instead, media flows transmitted by 106 conference participants are simply forwarded by the Media Distributor 107 to each of the other participants, often forwarding only a subset of 108 flows based on voice activity detection or other criteria. In some 109 instances, the Media Distributors may make limited modifications to 110 RTP [RFC3550] headers, for example, but the actual media content 111 (e.g., voice or video data) is unaltered. 113 An advantage of switched conferencing is that Media Distributors can 114 be more easily deployed on general-purpose computing hardware, 115 including virtualized environments in private and public clouds. 116 Deploying conference resources in a public cloud environment might 117 introduce a higher security risk. Whereas traditional conference 118 resources were usually deployed in private networks that were 119 protected, cloud-based conference resources might be viewed as less 120 secure since they are not always physically controlled by those who 121 use them. Additionally, there are usually several ports open to the 122 public in cloud deployments, such as for remote administration, and 123 so on. 125 This document defines a solution framework wherein media privacy is 126 ensured by making it impossible for a media distributor to gain 127 access to keys needed to decrypt or authenticate the actual media 128 content sent between conference participants. At the same time, the 129 framework allows for the Media Distributors to modify certain RTP 130 headers; add, remove, encrypt, or decrypt RTP header extensions; and 131 encrypt and decrypt RTCP packets. The framework also prevents replay 132 attacks by authenticating each packet transmitted between a given 133 participant and the media distributor using a unique key per endpoint 134 that is independent from the key for media encryption and 135 authentication. 137 A goal of this document is to define a framework for enhanced privacy 138 in RTP-based conferencing environments while utilizing existing 139 security procedures defined for RTP with minimal enhancements. 141 2. Conventions Used in This Document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119] when they 146 appear in ALL CAPS. These words may also appear in this document in 147 lower case as plain English words, absent their normative meanings. 149 Additionally, this solution framework uses the following terms and 150 acronyms: 152 End-to-End (E2E): Communications from one endpoint through one or 153 more Media Distributors to the endpoint at the other end. 155 Hop-by-Hop (HBH): Communications between an endpoint and a Media 156 Distributor or between Media Distributors. 158 Trusted Endpoint: An RTP flow terminating entity that has possession 159 of E2E media encryption keys and terminates E2E encryption. This may 160 include embedded user conferencing equipment or browsers on 161 computers, media gateways, MCUs, media recording device and more that 162 are in the trusted domain for a given deployment. 164 Media Distributor (MD): An RTP middlebox that is not allowed to to 165 have access to E2E encryption keys. It operates according to the 166 Selective Forwarding Middlebox RTP topologies [RFC7667] per the 167 constraints defined by the PERC system, which includes, but not 168 limited to, having no access to RTP media unencrypted and having 169 limits on what RTP header field it can alter. 171 Key Distributor: An entity that is a logical function which 172 distributes keying material and related information to trusted 173 endpoints and Media Distributor(s), only that which is appropriate 174 for each. The Key Distributor might be co-resident with another 175 entity trusted with E2E keying material. 177 Conference: Two or more participants communicating via trusted 178 endpoints to exchange RTP flows through one or more Media 179 Distributor. 181 Call Processing: All trusted endpoints in the conference connect to 182 it by a call processing dialog, such as with the Focus defined in the 183 Framework for Conferencing with SIP [RFC4353]. 185 Third Party: Any entity that is not an Endpoint, Media Distributor, 186 Key Distributor or Call Processing entity as described in this 187 document. 189 3. PERC Entities and Trust Model 191 The following figure depicts the trust relationships, direct or 192 indirect, between entities described in the subsequent sub-sections. 193 Note that these entities may be co-located or further divided into 194 multiple, separate physical devices. 196 Please note that some entities classified as untrusted in the simple, 197 general deployment scenario used most commonly in this document might 198 be considered trusted in other deployments. This document does not 199 preclude such scenarios, but will keep the definitions and examples 200 focused by only using the the simple, most general deployment 201 scenario. 203 | 204 +----------+ | +-----------------+ 205 | Endpoint | | | Call Processing | 206 +----------+ | +-----------------+ 207 | 208 | 209 +----------------+ | +--------------------+ 210 | Key Distributor| | | Media Distributor | 211 +----------------+ | +--------------------+ 212 | 213 Trusted | Untrusted 214 Entities | Entities 215 | 217 Figure 1: Trusted and Untrusted Entities in PERC 219 3.1. Untrusted Entities 221 The architecture described in this framework document enables 222 conferencing infrastructure to be hosted in domains, such as in a 223 cloud conferencing provider's facilities, where the trustworthiness 224 is below the level needed to assume the privacy of participant's 225 media will not be compromised. The conferencing infrastructure in 226 such a domain is still trusted with reliably connecting the 227 participants together in a conference, but not trusted with keying 228 material needed to decrypt any of the participant's media. Entities 229 in such lower trustworthiness domains will simply be referred to as 230 untrusted entities from this point forward. 232 It is important to understand that untrusted in this document does 233 not mean an entity is not expected to function properly. Rather, it 234 means only that the entity does not have access to the E2E media 235 encryption keys. 237 3.1.1. Media Distributor 239 A Media Distributor forwards RTP flows between endpoints in the 240 conference while performing per-hop authentication of each RTP 241 packet. The Media Distributor may need access to one or more RTP 242 headers or header extensions, potentially adding or modifying a 243 certain subset. The Media Distributor will also relay secured 244 messaging between the endpoints and the Key Distributor and will 245 acquire per-hop key information from the Key Distributor. The actual 246 media content MUST NOT not be decryptable by a Media Distributor, so 247 it is untrusted to have access to the E2E media encryption keys. The 248 key exchange mechanisms specified in this framework will prevent the 249 Media Distributor from gaining access to the E2E media encryption 250 keys. 252 An endpoint's ability to join a conference hosted by a Media 253 Distributor MUST NOT alone be interpreted as being authorized to have 254 access to the E2E media encryption keys, as the Media Distributor 255 does not have the ability to determine whether an endpoint is 256 authorized. Instead, the Key Distributor is responsible for 257 authenticating endpoints (e.g., using WebRTC Identity 258 [I-D.ietf-rtcweb-security-arch]) and determining their authorization 259 to receive E2E media encryption keys. 261 A Media Distributor MUST perform its role in properly forwarding 262 media packets while taking measures to mitigate the adverse effects 263 of denial of service attacks (refer to Section 6), etc, to a level 264 equal to or better than traditional conferencing (i.e. non-PERC) 265 deployments. 267 A Media Distributor or associated conferencing infrastructure may 268 also initiate or terminate various conference control related 269 messaging, which is outside the scope of this framework document. 271 3.1.2. Call Processing 273 The call processing function is untrusted in the simple, general 274 deployment scenario. When a physical subset of the call processing 275 function resides in facilities outside the trusted domain, it should 276 not be trusted to have access to E2E key information. 278 The call processing function may include the processing of call 279 signaling messages, as well as the signing of those messages. It may 280 also authenticate the endpoints for the purpose of call signaling and 281 subsequently joining of a conference hosted through one or more Media 282 Distributors. Call processing may optionally ensure the privacy of 283 call signaling messages between itself, the endpoint, and other 284 entities. 286 In any deployment scenario where the call processing function is 287 considered trusted, the call processing function MUST ensure the 288 integrity of received messages before forwarding to other entities. 290 3.2. Trusted Entities 292 From the PERC model system perspective, entities considered trusted 293 (refer to Figure 1) can be in possession of the E2E media encryption 294 keys for one or more conferences. 296 3.2.1. Endpoint 298 An endpoint is considered trusted and will have access to E2E key 299 information. While it is possible for an endpoint to be compromised, 300 subsequently performing in undesired ways, defining endpoint 301 resistance to compromise is outside the scope of this document. 302 Endpoints will take measures to mitigate the adverse effects of 303 denial of service attacks (refer to Section 6) from other entities, 304 including from other endpoints, to a level equal to or better than 305 traditional conference (i.e., non-PERC) deployments. 307 3.2.2. Key Distributor 309 The Key Distributor, which may be colocated with an endpoint or exist 310 standalone, is responsible for providing key information to endpoints 311 for both end-to-end and hop-by-hop security and for providing key 312 information to Media Distributors for the hop-by-hop security. 314 Interaction between the Key Distributor and the call processing 315 function is necessary to for proper conference-to-endpoint mappings. 316 This is described in Section 5.3. 318 The Key Distributor needs to be secured and managed in a way to 319 prevent exploitation by an adversary, as any kind of compromise of 320 the Key Distributor puts the security of the conference at risk. 322 4. Framework for PERC 324 The purpose for this framework is to define a means through which 325 media privacy can be ensured when communicating within a conferencing 326 environment consisting of one or more Media Distributors that only 327 switch, hence not terminate, media. It does not otherwise attempt to 328 hide the fact that a conference between endpoints is taking place. 330 This framework reuses several specified RTP security technologies, 331 including SRTP [RFC3711], PERC EKT [I-D.ietf-perc-srtp-ekt-diet], and 332 DTLS-SRTP [RFC5764]. 334 4.1. End-to-End and Hop-by-Hop Authenticated Encryption 336 This solution framework focuses on the end-to-end privacy and 337 integrity of the participant's media by limiting access of the end- 338 to-end key information to trusted entities. However, this framework 339 does give a Media Distributor access to RTP headers and all or most 340 header extensions, as well as the ability to modify a certain subset 341 of those headers and to add header extensions. Packets received by a 342 Media Distributor or an endpoint are authenticated hop-by-hop. 344 To enable all of the above, this framework defines the use of two 345 security contexts and two associated encryption keys: an "inner" key 346 (an E2E key distinct for each transmitted media flow) for 347 authenticated encryption of RTP media between endpoints and an 348 "outer" key (HBH key) known only to media distributor and the 349 adjacent endpoint) for the hop between an endpoint and a Media 350 Distributor or between Media Distributor. 352 +-------------+ +-------------+ 353 | |################################| | 354 | Media |------------------------ *----->| Media | 355 | Distributor |<----------------------*-|------| Distributor | 356 | X |#####################*#|#|######| Y | 357 | | | | | | | 358 +-------------+ | | | +-------------+ 359 # ^ | # HBH Key (XY) -+ | | # ^ | # 360 # | | # E2E Key (B) ---+ | # | | # 361 # | | # E2E Key (A) -----+ # | | # 362 # | | # # | | # 363 # | | # # | | # 364 # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # 365 # | | # # | | # 366 # *--------- E2E Key (A) E2E Key (A) ---------* # 367 # | *------- E2E Key (B) E2E Key (B) -------* | # 368 # | | # # | | # 369 # | v # # | v # 370 +-------------+ +-------------+ 371 | Endpoint A | | Endpoint B | 372 +-------------+ +-------------+ 374 E2E and HBH Keys Used for Authenticated Encryption of SRTP Packets 376 The PERC Double transform [I-D.ietf-perc-double] enables endpoints to 377 perform encryption using both the E2E and HBH contexts while still 378 preserving the same overall interface as other SRTP transforms. The 379 Media Distributor simply uses the corresponding normal (single) AES- 380 GCM transform, keyed with the appropriate HBH keys. See Appendix A 381 for a description of the keys used in PERC and Appendix B for an 382 overview of how the packet appears on the wire. 384 RTCP can only be encrypted hop-by-hop, not end-to-end. This 385 framework introduces no additional step for RTCP authenticated 386 encryption, so the procedures needed are specified in [RFC3711] and 387 use the same outer, hop-by-hop cryptographic context chosen in the 388 Double operation described above. 390 4.2. E2E Key Confidentiality 392 To ensure the confidentiality of E2E keys shared between endpoints, 393 endpoints will make use of a common Key Encryption Key (KEK) that is 394 known only by the trusted entities in a conference. That KEK, 395 defined in the PERC EKT [I-D.ietf-perc-srtp-ekt-diet] as the EKT Key, 396 will be used to subsequently encrypt the SRTP master key used for E2E 397 authenticated encryption of media sent by a given endpoint. Each 398 endpoint in the conference will create a random SRTP master key for 399 E2E authenticated encryption, thus participants in the conference 400 MUST keep track of the E2E keys received via the Full EKT Field for 401 each distinct SSRC in the conference so that it can properly decrypt 402 received media. Note, too, that an endpoint may change its E2E key 403 at any time and advertise that new key to the conference as specified 404 in [I-D.ietf-perc-srtp-ekt-diet]. 406 4.3. E2E Keys and Endpoint Operations 408 Any given RTP media flow can be identified by its SSRC, and endpoints 409 might send more than one at a time and change the mix of media flows 410 transmitted during the life of a conference. 412 Thus, endpoints MUST maintain a list of SSRCs from received RTP flows 413 and each SSRC's associated E2E key information. Following a change 414 in an E2E key, prior E2E keys SHOULD be retained by receivers for a 415 period long enough to ensure that late-arriving or out-of-order 416 packets from the endpoint can be successfully decrypted. Receiving 417 endpoints MUST discard old E2E keys no later than when it leaves the 418 conference. 420 If there is a need to encrypt one or more RTP header extensions end- 421 to-end, an encryption key is derived from the end-to-end SRTP master 422 key to encrypt header extensions as per [RFC6904]. The Media 423 Distributor will not be able use the information contained in those 424 header extensions encrypted with an E2E key. 426 4.4. HBH Keys and Hop Operations 428 To ensure the integrity of transmitted media packets, this framework 429 requires that every packet be authenticated hop-by-hop (HBH) between 430 an endpoint and a Media Distributor, as well between Media 431 Distributors. The authentication key used for hop-by-hop 432 authentication is derived from an SRTP master key shared only on the 433 respective hop. Each HBH key is distinct per hop and no two hops 434 ever use the same SRTP master key. 436 Using hop-by-hop authentication gives the Media Distributor the 437 ability to change certain RTP header values. Which values the Media 438 Distributor can change in the RTP header are defined in 439 [I-D.ietf-perc-double]. RTCP can only be encrypted HBH, giving the 440 Media Distributor the flexibility to forward RTCP content unchanged, 441 transmit compound RTCP packets or to initiate RTCP packets for 442 reporting statistics or conveying other information. Performing hop- 443 by-hop authentication for all RTP and RTCP packets also helps provide 444 replay protection (see Section 6). 446 If there is a need to encrypt one or more RTP header extensions hop- 447 by-hop, an encryption key is derived from the hop-by-hop SRTP master 448 key to encrypt header extensions as per [RFC6904]. This will still 449 give the Media Distributor visibility into header extensions, such as 450 the one used to determine audio level [RFC6464] of conference 451 participants. Note that when RTP header extensions are encrypted, 452 all hops - in the untrusted domain at least - will need to decrypt 453 and re-encrypt these encrypted header extensions. 455 4.5. Key Exchange 457 In brief, the keys used by any given endpoints are determined in the 458 following way: 460 o The HBH keys that the endpoint uses to send and receive SRTP media 461 are derived from a DTLS handshake that the endpoint performs with 462 the Key Distributor (following normal DTLS-SRTP procedures). 464 o The E2E key that an endpoint uses to send SRTP media can either be 465 set from DTLS or chosen by the endpoint. It is then distributed 466 to other endpoints in a Full EKT Field, encrypted under an EKTKey 467 provided to the client by the Key Distributor within the DTLS 468 channel they negotiated. 470 o Each E2E key that an endpoint uses to receive SRTP media is set by 471 receiving a Full EKT Field from another endpoint. 473 4.5.1. Initial Key Exchange and Key Distributor 475 The Media Distributor maintains a tunnel with the Key Distrubutor 476 (e.g., using [I-D.ietf-perc-dtls-tunnel]), making it possible for the 477 Media Distributor to facilitate the establishment of a secure DTLS 478 association between each endpoint and the Key Distributor as shown 479 the following figure. The DTLS association between endpoints and the 480 Key Distributor will enable each endpoint to generate E2E and HBH 481 keys and receive the Key Encryption Key (KEK) (i.e., EKT Key). At 482 the same time, the Key Distributor can securely provide the HBH key 483 information to the Media Distributor. The key information summarized 484 here may include the SRTP master key, SRTP master salt, and the 485 negotiated cryptographic transform. 487 +-----------+ 488 KEK info | Key | HBH Key info to 489 to Endpoints |Distributor| Endpoints & Media Distributor 490 +-----------+ 491 # ^ ^ # 492 # | | #--- Tunnel 493 # | | # 494 +-----------+ +-----------+ +-----------+ 495 | Endpoint | DTLS | Media | DTLS | Endpoint | 496 | KEK |<------------|Distributor|------------>| KEK | 497 | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | 498 +-----------+ +-----------+ +-----------+ 500 Figure 2: Exchanging Key Information Between Entities 502 Endpoints will establish a DTLS-SRTP [RFC5764] association over the 503 RTP session's media ports for the purposes of key information 504 exchange with the Key Distributor. The Media Distributor will not 505 terminate the DTLS signaling, but will instead forward DTLS packets 506 received from an endpoint on to the Key Distributor (and vice versa) 507 via a tunnel established between Media Distributor and the Key 508 Distributor. This tunnel is used to encapsulate the DTLS-SRTP 509 signaling between the Key Distributor and endpoints will also be used 510 to convey HBH key information from the Key Distributor to the Media 511 Distributor, so no additional protocol or interface is required. 513 In establishing the DTLS association between endpoints and the Key 514 Distributor, the endpoint MUST act as the DTLS client and the Key 515 Distributor MUST act as the DTLS server. The Key Encryption Key 516 (KEK) (i.e., EKT Key) is conveyed by the Key Distributor over the 517 DTLS association to endpoints via procedures defined in PERC EKT 518 [I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message. 520 Note that following DTLS-SRTP procedures for the 521 [I-D.ietf-perc-double] cipher, the endpoint will generate both E2E 522 and HBH encryption keys and salt values. Endpoints MAY use the DTLS- 523 SRTP generated E2E key for transmission or MAY generate a fresh E2E 524 key. In either case, the generated SRTP master salt for E2E 525 encryption MUST be replaced with the salt value provided by the Key 526 Distributor via the EKTKey message. That is because every endpoint 527 in the conference uses the same SRTP master salt. The endpoint only 528 transmits the SRTP master key (not the salt) used for E2E encryption 529 to other endpoints in RTP/RTCP packets per 530 [I-D.ietf-perc-srtp-ekt-diet]. 532 Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media 533 Distributor to establish the HBH key for transmitting RTP and RTCP 534 packets to that peer Media Distributor. The Key Distributor does not 535 facilitate establishing a HBH key for use between Media Distributors. 537 4.5.2. Key Exchange during a Conference 539 Following the initial key information exchange with the Key 540 Distributor, an endpoint will be able to encrypt media end-to-end 541 with an E2E key, sending that E2E key to other endpoints encrypted 542 with the KEK, and will be able to encrypt and authenticate RTP 543 packets using a HBH key. The procedures defined do not allow the 544 Media Distributor to gain access to the KEK information, preventing 545 it from gaining access to any endpoint's E2E key and subsequently 546 decrypting media. 548 The KEK (i.e., EKT Key) may need to change from time-to-time during 549 the life of a conference, such as when a new participant joins or 550 leaves a conference. Dictating if, when or how often a conference is 551 to be re-keyed is outside the scope of this document, but this 552 framework does accommodate re-keying during the life of a conference. 554 When a Key Distributor decides to re-key a conference, it transmits a 555 specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to 556 each of the conference participants. The endpoint MUST create a new 557 SRTP master key and prepare to send that key inside a Full EKT Field 558 using the new EKTKey. Since it may take some time for all of the 559 endpoints in conference to finish re-keying, senders MUST delay a 560 short period of time before sending media encrypted with the new 561 master key, but it MUST be prepared to make use of the information 562 from a new inbound EKT Key immediately. See Section 2.2.2 of 563 [I-D.ietf-perc-srtp-ekt-diet]. 565 Endpoints MAY follow the procedures in section 5.2 of [RFC5764] to 566 re-negotiate HBH keys as desired. If new HBH keys are generated, the 567 new keys are also delivered to the Media Distributor following the 568 procedures defined in [I-D.ietf-perc-dtls-tunnel]. 570 Endpoints are at liberty to change the E2E encryption key used at any 571 time. Endpoints MUST generate a new E2E encryption key whenever it 572 receives a new EKT Key. After switching to a new key, the new key 573 will be conveyed to other endpoints in the conference in RTP/RTCP 574 packets per [I-D.ietf-perc-srtp-ekt-diet]. 576 5. Authentication 578 It is important to this solution framework that the entities can 579 validate the authenticity of other entities, especially the Key 580 Distributor and endpoints. The details of this are outside the scope 581 of specification but a few possibilities are discussed in the 582 following sections. The key requirements is that endpoints can 583 verify they are connected to the correct Key Distributor for the 584 conference and the Key Distributor can verify the endpoints are the 585 correct endpoints for the conference. 587 Two possible approaches to solve this are Identity Assertions and 588 Certificate Fingerprints. 590 5.1. Identity Assertions 592 WebRTC Identity assertion [I-D.ietf-rtcweb-security-arch] can be used 593 to bind the identity of the user of the endpoint to the fingerprint 594 of the DTLS-SRTP certificate used for the call. This certificate is 595 unique for a given call and a conference. This allows the Key 596 Distributor to ensure that only authorized users participate in the 597 conference. Similarly the Key Distributor can create a WebRTC 598 Identity assertion to bind the fingerprint of the unique certificate 599 used by the Key Distributor for this conference so that the endpoint 600 can validate it is talking to the correct Key Distributor. Such a 601 setup requires an Identity Provider (Idp) trusted by the endpoints 602 and the Key Distributor. 604 5.2. Certificate Fingerprints in Session Signaling 606 Entities managing session signaling are generally assumed to be 607 untrusted in the PERC framework. However, there are some deployment 608 scenarios where parts of the session signaling may be assumed 609 trustworthy for the purposes of exchanging, in a manner that can be 610 authenticated, the fingerprint of an entity's certificate. 612 As a concrete example, SIP [RFC3261] and SDP [RFC4566] can be used to 613 convey the fingerprint information per [RFC5763]. An endpoint's SIP 614 User Agent would send an INVITE message containing SDP for the media 615 session along with the endpoint's certificate fingerprint, which can 616 be signed using the procedures described in [RFC4474] for the benefit 617 of forwarding the message to other entities by the Focus [RFC4353]. 618 Other entities can now verify the fingerprints match the certificates 619 found in the DTLS-SRTP connections to find the identity of the far 620 end of the DTLS-SRTP connection and check that is the authorized 621 entity. 623 Ultimately, if using session signaling, an endpoint's certificate 624 fingerprint would need to be securely mapped to a user and conveyed 625 to the Key Distributor so that it can check that that user is 626 authorized. Similarly, the Key Distributor's certificate fingerprint 627 can be conveyed to endpoint in a manner that can be authenticated as 628 being an authorized Key Distributor for this conference. 630 5.3. Conferences Identification 632 The Key Distributor needs to know what endpoints are being added to a 633 given conference. Thus, the Key Distributor and the Media 634 Distributor will need to know endpoint-to-conference mappings, which 635 is enabled by exchanging a conference-specific unique identifier as 636 defined in [I-D.ietf-perc-dtls-tunnel]. How this unique identifier 637 is assigned is outside the scope of this document. 639 6. Security Considerations 641 This framework, and the individual protocols defined to support it, 642 must take care to not increase the exposure to Denial of Service 643 (DoS) attacks by untrusted or third-party entities and should take 644 measures to mitigate, where possible, more serious DoS attacks from 645 on-path and off-path attackers. 647 The following section enumerates the kind of attacks that will be 648 considered in the development of this framework's solution. 650 6.1. Third Party Attacks 652 On-path attacks are mitigated by HBH integrity protection and 653 encryption. The integrity protection mitigates packet modification 654 and encryption makes selective blocking of packets harder, but not 655 impossible. 657 Off-path attackers may try connecting to different PERC entities and 658 send specifically crafted packets. A successful attacker might be 659 able to get the Media Distributor to forward such packets. If not 660 making use of HBH authentication on the Media Distributor, such an 661 attack could only be detected in the receiving endpoints where the 662 forged packets would finally be dropped. 664 Another potential attack is a third party claiming to be a Media 665 Distributor, fooling endpoints in to sending packets to the false 666 Media Distributor instead of the correct one. The deceived sending 667 endpoints could incorrectly assuming their packets have been 668 delivered to endpoints when they in fact have not. Further, the 669 false Media Distributor may cascade to another legitimate Media 670 Distributor creating a false version of the real conference. 672 This attack can be mitigated by the false Media Distributor not being 673 authenticated by the Key Distributor during PERC Tunnel 674 establishment. Without the tunnel in place, endpoints will not 675 establish secure associations with the Key Distributor and receive 676 the KEK, causing the conference to not proceed. 678 6.2. Media Distributor Attacks 680 The Media Distributor can attack the session in a number of possible 681 ways. 683 6.2.1. Denial of service 685 Any modification of the end-to-end authenticated data will result in 686 the receiving endpoint getting an integrity failure when performing 687 authentication on the received packet. 689 The Media Distributor can also attempt to perform resource 690 consumption attacks on the receiving endpoint. One such attack would 691 be to insert random SSRC/CSRC values in any RTP packet with an inband 692 key-distribution message attached (i.e., Full EKT Field). Since such 693 a message would trigger the receiver to form a new cryptographic 694 context, the Media Distributor can attempt to consume the receiving 695 endpoints resources. 697 Another denial of service attack is where the Media Distributor 698 rewrites the PT field to indicate a different codec. The effect of 699 this attack is that any payload packetized and encoded according to 700 one RTP payload format is then processed using another payload format 701 and codec. Assuming that the implementation is robust to random 702 input, it is unlikely to cause crashes in the receiving software/ 703 hardware. However, it is not unlikely that such rewriting will cause 704 severe media degradation. 706 For audio formats, this attack is likely to cause highly disturbing 707 audio and/or can be damaging to hearing and playout equipment. 709 6.2.2. Replay Attack 711 Replay attack is when an already received packets from a previous 712 point in the RTP stream is replayed as new packet. This could, for 713 example, allow a Media Distributor to transmit a sequence of packets 714 identified as a user saying "yes", instead of the "no" the user 715 actually said. 717 The mitigation for a replay attack is to prevent old packets beyond a 718 small-to-modest jitter and network re-ordering sized window to be 719 rejected. End-to-end replay protection MUST be provided for the 720 whole duration of the conference. 722 6.2.3. Delayed Playout Attack 724 The delayed playout attack is a variant of the replay attack. This 725 attack is possible even if E2E replay protection is in place. 726 However, due to fact that the Media Distributor is allowed to select 727 a sub-set of streams and not forward the rest to a receiver, such as 728 in forwarding only the most active speakers, the receiver has to 729 accept gaps in the E2E packet sequence. The issue with this is that 730 a Media Distributor can select to not deliver a particular stream for 731 a while. 733 Within the window from last packet forwarded to the receiver and the 734 latest received by the Media Distributor, the Media Distributor can 735 select an arbitrary starting point when resuming forwarding packets. 736 Thus what the media source said can be substantially delayed at the 737 receiver with the receiver believing that it is what was said just 738 now, and only delayed due to transport delay. 740 6.2.4. Splicing Attack 742 The splicing attack is an attack where a Media Distributor receiving 743 multiple media sources splices one media stream into the other. If 744 the Media Distributor is able to change the SSRC without the receiver 745 having any method for verifying the original source ID, then the 746 Media Distributor could first deliver stream A and then later forward 747 stream B under the same SSRC as stream A was previously using. Not 748 allowing the Media Distributor to change the SSRC mitigates this 749 attack. 751 7. IANA Considerations 753 There are no IANA considerations for this document. 755 8. Acknowledgments 757 The authors would like to thank Mo Zanaty and Christian Oien for 758 invaluable input on this document. Also, we would like to 759 acknowledge Nermeen Ismail for serving on the initial versions of 760 this document as a co-author. 762 9. References 764 9.1. Normative References 766 [I-D.ietf-perc-double] 767 Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP 768 Double Encryption Procedures", draft-ietf-perc-double-08 769 (work in progress), March 2018. 771 [I-D.ietf-perc-dtls-tunnel] 772 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 773 between a Media Distributor and Key Distributor to 774 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-02 775 (work in progress), October 2017. 777 [I-D.ietf-perc-srtp-ekt-diet] 778 Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. 779 Andreasen, "Encrypted Key Transport for DTLS and Secure 780 RTP", draft-ietf-perc-srtp-ekt-diet-07 (work in progress), 781 March 2018. 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, 785 DOI 10.17487/RFC2119, March 1997, 786 . 788 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 789 Jacobson, "RTP: A Transport Protocol for Real-Time 790 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 791 July 2003, . 793 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 794 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 795 RFC 3711, DOI 10.17487/RFC3711, March 2004, 796 . 798 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 799 Security (DTLS) Extension to Establish Keys for the Secure 800 Real-time Transport Protocol (SRTP)", RFC 5764, 801 DOI 10.17487/RFC5764, May 2010, 802 . 804 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 805 Real-time Transport Protocol (SRTP)", RFC 6904, 806 DOI 10.17487/RFC6904, April 2013, 807 . 809 9.2. Informative References 811 [I-D.ietf-rtcweb-security-arch] 812 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 813 rtcweb-security-arch-13 (work in progress), October 2017. 815 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 816 A., Peterson, J., Sparks, R., Handley, M., and E. 817 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 818 DOI 10.17487/RFC3261, June 2002, 819 . 821 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 822 Session Initiation Protocol (SIP)", RFC 4353, 823 DOI 10.17487/RFC4353, February 2006, 824 . 826 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 827 Authenticated Identity Management in the Session 828 Initiation Protocol (SIP)", RFC 4474, 829 DOI 10.17487/RFC4474, August 2006, 830 . 832 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 833 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 834 July 2006, . 836 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 837 for Establishing a Secure Real-time Transport Protocol 838 (SRTP) Security Context Using Datagram Transport Layer 839 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 840 2010, . 842 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 843 Transport Protocol (RTP) Header Extension for Client-to- 844 Mixer Audio Level Indication", RFC 6464, 845 DOI 10.17487/RFC6464, December 2011, 846 . 848 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 849 DOI 10.17487/RFC7667, November 2015, 850 . 852 Appendix A. PERC Key Inventory 854 PERC specifies the use of a number of different keys and, 855 understandably, it looks complicated or confusing on the surface. 856 This section summarizes the various keys used in the system, how they 857 are generated, and what purpose they serve. 859 The keys are described in the order in which they would typically be 860 acquired. 862 The various keys used in PERC are shown in Figure 3 below. 864 +-----------+----------------------------------------------------+ 865 | Key | Description | 866 +-----------+----------------------------------------------------+ 867 | KEK | Key shared by all endpoints and used to encrypt | 868 | (EKT Key) | each endpoint's SRTP master key so receiving | 869 | | endpoints can decrypt media. | 870 +-----------+----------------------------------------------------+ 871 | HBH Key | Key used to encrypt media hop-by-hop. | 872 +-----------+----------------------------------------------------+ 873 | E2E Key | Key used to encrypt media end-to-end. | 874 +-----------+----------------------------------------------------+ 876 Figure 3: Key Inventory 878 As you can see, the number key types is very small. However, what 879 can be challenging is keeping track of all of the distinct E2E keys 880 as the conference grows in size. With 1,000 participants in a 881 conference, there will be 1,000 distinct SRTP master keys, all of 882 which share the same master salt. Each of those keys are passed 883 through the KDF defined in [RFC3711] to produce the actual encryption 884 and authentication keys. Complicating key management is the fact 885 that the KEK can change and, when it does, the endpoints generate new 886 SRTP master keys. And, of course, there is a new SRTP master salt to 887 go with those keys. Endpoints have to retain old keys for a period 888 of time to ensure they can properly decrypt late-arriving or out-of- 889 order packets. 891 The time required to retain old keys (either EKT Keys or SRTP master 892 keys) is not specified, but they should be retained at least for the 893 period of time required to re-key the conference or handle late- 894 arriving or out-of-order packets. A period of 60s should be 895 considered a generous retention period, but endpoints may keep old 896 keys on hand until the end of the conference. 898 Or more detailed explanation of each of the keys follows. 900 A.1. DTLS-SRTP Exchange Yields HBH Keys 902 The first set of keys acquired are for hop-by-hop encryption and 903 decryption. Assuming the use of Double [I-D.ietf-perc-double], the 904 endpoint would perform DTLS-SRTP exchange with the key distributor 905 and receive a key that is, in fact, "double" the size that is needed. 906 Per the Double specification, the E2E part is the first half of the 907 key, so the endpoint will just discard that information in PERC. It 908 is not used. The second half of the key material is for HBH 909 operations, so that half of the key (corresponding to the least 910 significant bits) is assigned internally as the HBH key. 912 The media distributor doesn't perform DTLS-SRTP, but it is at this 913 point that the key distributor will inform the media distributor of 914 the HBH key value via the tunnel protocol 915 ([I-D.ietf-perc-dtls-tunnel]). The key distributor will send the 916 least significant bits corresponding to the half of the keying 917 material determined through DTLS-SRTP with the endpoint to the media 918 distributor via the tunnel protocol. There is a salt generated along 919 with the HBH key. The salt is also longer than needed for HBH 920 operations, thus only the least significant bits of the required 921 length (i.e., half of the generated salt material) are sent to the 922 media distributor via the tunnel protocol. 924 No two endpoints will have the same HBH key, thus the media 925 distributor must keep track each distinct HBH key (and the 926 corresponding salt) and use it only for the specified hop. 928 This key is also used for HBH encryption of RTCP. RTCP is not end- 929 to-end encrypted in PERC. 931 A.2. The Key Distributor Transmits the KEK (EKT Key) 933 Via the aforementioned DTLS-SRTP association, the key distributor 934 will send the endpoint the KEK (i.e., EKT Key per 935 [I-D.ietf-perc-srtp-ekt-diet]). This key is known only to the key 936 distributor and endpoints. This key is the most important to protect 937 since having knowledge of this key (and the SRTP master salt 938 transmitted as a part of the same message) will allow an entity to 939 decrypt any media packet in the conference. 941 Note that the key distributor can send any number of EKT Keys to 942 endpoints. This can be used to re-key the entire conference. Each 943 key is identified by a "Security Parameter Index" (SPI) value. 944 Endpoints should expect that a conference might be re-keyed when a 945 new participant joins a conference or when a participant leaves a 946 conference in order to protect the confidentiality of the 947 conversation before and after such events. 949 The SRTP master salt to be used by the endpoint is transmitted along 950 with the EKT Key. All endpoints in the conference utilize the same 951 SRTP master salt that corresponds with a given EKT Key. 953 The EKT Field in media packets is encrypted using a cipher specified 954 via the EKTKey message (e.g., AES Key Wrap with a 128-bit key). This 955 cipher is different than the cipher used to protect media and is only 956 used to encrypt the endpoint's SRTP master key (and other EKT Field 957 data as per [I-D.ietf-perc-srtp-ekt-diet]). 959 The media distributor is not given the KEK (i.e., EKT Key). 961 A.3. Endpoints fabricate an SRTP Master Key 963 As stated earlier, the E2E key determined via DTLS-SRTP MAY be 964 discarded in favor of a locally-generated SRTP master key. While the 965 DTLS-SRTP-derived key could be used, the fact that an endpoint might 966 need to change the SRTP master key periodically or is forced to 967 change the SRTP master key as a result of the EKT key changing means 968 using it has only limited utility. To reduce complexity, PERC 969 *RECOMMENDS* that endpoints create random SRTP master keys locally to 970 be used for E2E encryption. 972 This locally-generated SRTP master key is used along with the master 973 salt transmitted to the endpoint from the key distributor via the 974 EKTKey message to encrypt media end-to-end. 976 Since the media distributor is not involved in E2E functions, it will 977 not create this key nor have access to any endpoint's E2E key. Note, 978 too, that even the key distributor is unaware of the locally- 979 generated E2E keys used by each endpoint. 981 The endpoint will transmit its E2E key to other endpoints in the 982 conference by periodically including it in SRTP packets in a Full EKT 983 Field. When placed in the Full EKT Field, it is encrypted using the 984 EKT Key provided by the key distributor. The master salt is not 985 transmitted, though, since all endpoints will have received the same 986 master salt via the EKTKey message. The recommended frequency with 987 which an endpoint transmits its SRTP master key is specified in 988 [I-D.ietf-perc-srtp-ekt-diet]. 990 A.4. Who has What Key 992 All endpoints have knowledge of the KEK. 994 Every HBH key is distinct for a given endpoint, thus Endpoint A and 995 endpoint B do not have knowledge of the other's HBH key. 997 Each endpoint generates its own E2E Key (SRTP master key), thus the 998 key distinct per endpoint. This key is transmitted (encrypted) via 999 the EKT Field to other endpoints. Endpoints that receive media from 1000 a given transmitting endpoint will therefore have knowledge of the 1001 transmitter's E2E key. 1003 To summarize the various keys and which entity is in possession of a 1004 given key, refer to Figure 4. 1006 +----------------------+------------+-------+-------+------------+ 1007 | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | 1008 +----------------------+------------+-------+-------+------------+ 1009 | KEK | Yes | No | No | Yes | 1010 +----------------------+------------+-------+-------+------------+ 1011 | E2E Key (A and B) | Yes | No | No | Yes | 1012 +----------------------+------------+-------+-------+------------+ 1013 | HBH Key (A<=>MD X) | Yes | Yes | No | No | 1014 +----------------------+------------+-------+-------+------------+ 1015 | HBH Key (B<=>MD Y) | No | No | Yes | Yes | 1016 +----------------------+------------+---------------+------------+ 1017 | HBH Key (MD X<=>MD Y)| No | Yes | Yes | No | 1018 +----------------------+------------+---------------+------------+ 1020 Figure 4: Keys per Entity 1022 Appendix B. PERC Packet Format 1024 Figure 5 presents a complete picture of what a PERC packet looks like 1025 when transmitted over the wire. 1027 0 1 2 3 1028 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 A |V=2|P|X| CC |M| PT | sequence number | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 A | timestamp | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 A | synchronization source (SSRC) identifier | 1035 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1036 A | contributing source (CSRC) identifiers | 1037 A | .... | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 A | RTP extension (OPTIONAL) | 1040 A | (including the OHB) | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 C : : 1043 C : Ciphertext Payload : 1044 C : : 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 R : : 1047 R : EKT Field : 1048 R : : 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 C = Ciphertext (encrypted and authenticated) 1052 A = Associated Data (authenticated only) 1053 R = neither encrypted nor authenticated, added 1054 after Authenticated Encryption completed 1056 Figure 5: PERC Packet Format 1058 Authors' Addresses 1060 Paul E. Jones 1061 Cisco 1062 7025 Kit Creek Rd. 1063 Research Triangle Park, North Carolina 27709 1064 USA 1066 Phone: +1 919 476 2048 1067 Email: paulej@packetizer.com 1068 David Benham 1069 Cisco 1070 170 West Tasman Drive 1071 San Jose, California 95134 1072 USA 1074 Email: dbenham@cisco.com 1076 Christian Groves 1077 Independent 1078 Melbourne 1079 Australia 1081 Email: Christian.Groves@nteczone.com