idnits 2.17.1 draft-ietf-perc-double-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 : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2017) is 2446 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) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-20) exists of draft-ietf-payload-flexible-fec-scheme-05 == Outdated reference: A later version (-12) exists of draft-ietf-perc-dtls-tunnel-01 == Outdated reference: A later version (-12) exists of draft-ietf-perc-private-media-framework-04 == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-05 == Outdated reference: A later version (-10) exists of draft-ietf-rtcweb-fec-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft P. Jones 4 Intended status: Standards Track R. Barnes 5 Expires: February 9, 2018 Cisco Systems 6 A. Roach 7 Mozilla 8 August 8, 2017 10 SRTP Double Encryption Procedures 11 draft-ietf-perc-double-06 13 Abstract 15 In some conferencing scenarios, it is desirable for an intermediary 16 to be able to manipulate some RTP parameters, while still providing 17 strong end-to-end security guarantees. This document defines SRTP 18 procedures that use two separate but related cryptographic operations 19 to provide hop-by-hop and end-to-end security guarantees. Both the 20 end-to-end and hop-by-hop cryptographic algorithms can utilize an 21 authenticated encryption with associated data scheme or take 22 advantage of future SRTP transforms with different properties. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 9, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Cryptographic Context . . . . . . . . . . . . . . . . . . . . 4 61 4. Original Header Block . . . . . . . . . . . . . . . . . . . . 4 62 5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 5 64 5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6 65 5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 7 66 6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 8 68 7.1. RTX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.2. RED . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.3. FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.4. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Recommended Inner and Outer Cryptographic Algorithms . . . . 9 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 10.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 11 76 10.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . 11 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 12.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Appendix A. Encryption Overview . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 Cloud conferencing systems that are based on switched conferencing 87 have a central Media Distributor device that receives media from 88 endpoints and distributes it to other endpoints, but does not need to 89 interpret or change the media content. For these systems, it is 90 desirable to have one cryptographic key from the sending endpoint to 91 the receiving endpoint that can encrypt and authenticate the media 92 end-to-end while still allowing certain RTP header information to be 93 changed by the Media Distributor. At the same time, a separate 94 cryptographic key provides integrity and optional confidentiality for 95 the media flowing between the Media Distributor and the endpoints. 97 See the framework document that describes this concept in more detail 98 in more detail in [I-D.ietf-perc-private-media-framework]. 100 This specification defines an SRTP transform that uses the AES-GCM 101 algorithm [RFC7714] to provide encryption and integrity for an RTP 102 packet for the end-to-end cryptographic key as well as a hop-by-hop 103 cryptographic encryption and integrity between the endpoint and the 104 Media Distributor. The Media Distributor decrypts and checks 105 integrity of the hop-by-hop security. The Media Distributor MAY 106 change some of the RTP header information that would impact the end- 107 to-end integrity. The original value of any RTP header field that is 108 changed is included in a new RTP header extension called the Original 109 Header Block. The new RTP packet is encrypted with the hop-by-hop 110 cryptographic algorithm before it is sent. The receiving endpoint 111 decrypts and checks integrity using the hop-by-hop cryptographic 112 algorithm and then replaces any parameters the Media Distributor 113 changed using the information in the Original Header Block before 114 decrypting and checking the end-to-end integrity. 116 One can think of the double as a normal SRTP transform for encrypting 117 the RTP in a way where things that only know half of the key, can 118 decrypt and modify part of the RTP packet but not other parts of if 119 including the media payload. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 Terms used throughout this document include: 129 o Media Distributor: media distribution device that routes media 130 from one endpoint to other endpoints 132 o end-to-end: meaning the link from one endpoint through one or more 133 Media Distributors to the endpoint at the other end. 135 o hop-by-hop: meaning the link from the endpoint to or from the 136 Media Distributor. 138 o OHB: Original Header Block is an octet string that contains the 139 original values from the RTP header that might have been changed 140 by a Media Distributor. 142 3. Cryptographic Context 144 This specification uses a cryptographic context with two parts: an 145 inner (end-to-end) part that is used by endpoints that originate and 146 consume media to ensure the integrity of media end-to-end, and an 147 outer (hop-by-hop) part that is used between endpoints and Media 148 Distributors to ensure the integrity of media over a single hop and 149 to enable a Media Distributor to modify certain RTP header fields. 150 RTCP is also handled using the hop-by-hop cryptographic part. The 151 RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is 152 AES-GCM. Other combinations of SRTP ciphers that support the 153 procedures in this document can be added to the IANA registry. 155 The keys and salt for these algorithms are generated with the 156 following steps: 158 o Generate key and salt values of the length required for the 159 combined inner (end-to-end) and outer (hop-by-hop) algorithms. 161 o Assign the key and salt values generated for the inner (end-to- 162 end) algorithm to the first half of the key and salt for the 163 double algorithm. 165 o Assign the key and salt values for the outer (hop-by-hop) 166 algorithm to the second half of the key and salt for the double 167 algorithm. The first half of the key is referred to as the inner 168 key while the second half is referred to as the outer key. When a 169 key is used by a cryptographic algorithm, the salt used is the 170 part of the salt generated with that key. 172 Obviously, if the Media Distributor is to be able to modify header 173 fields but not decrypt the payload, then it must have cryptographic 174 key for the outer algorithm, but not the inner (end-to-end) 175 algorithm. This document does not define how the Media Distributor 176 should be provisioned with this information. One possible way to 177 provide keying material for the outer (hop-by-hop) algorithm is to 178 use [I-D.ietf-perc-dtls-tunnel]. 180 4. Original Header Block 182 The Original Header Block (OHB) contains the original values of any 183 modified header fields. In the encryption process, the OHB is 184 appended to the RTP payload. In the decryption process, the 185 receiving endpoint uses it to reconstruct the original RTP header, so 186 that it can pass the proper AAD value to the inner transform. 188 The OHB can reflect modifications to the following fields in an RTP 189 header: the payload type, the sequence number, and the marker bit. 191 All other fields in the RTP header MUST remain unmodified; since the 192 OHB cannot reflect their original values, the receiver will be unable 193 to verify the E2E integrity of the packet. 195 The OHB has the following syntax (in ABNF): 197 BYTE = %x00-FF 199 PT = BYTE 200 SEQ = 2BYTE 201 Config = BYTE 203 OHB = ?PT ?SEQ Config 205 If present, the PT and SEQ parts of the OHB contain the original 206 payload type and sequence number fields, respectively. The final 207 "config" octet of the OHB specifies whether these fields are present, 208 and the original value of the marker bit (if necessary): 210 +-+-+-+-+-+-+-+-+ 211 |R R R R B M P Q| 212 +-+-+-+-+-+-+-+-+ 214 o P: PT is present 216 o Q: SEQ is present 218 o M: Marker bit is present 220 o B: Value of marker bit 222 o R: Reserved, MUST be set to 0 224 In particular, an all-zero OHB config octet (0x00) indicates that 225 there have been no modifications from the original header. 227 5. RTP Operations 229 5.1. Encrypting a Packet 231 To encrypt a packet, the endpoint encrypts the packet using the inner 232 (end-to-end) cryptographic key and then encrypts using the outer 233 (hop-by-hop) cryptographic key. The encryption also supports a mode 234 for repair packets that only does the outer (hop-by-hop) encryption. 235 The processes is as follows: 237 1. Form an RTP packet. If there are any header extensions, they 238 MUST use [RFC5285]. 240 2. If the packet is for repair mode data, skip to step 6. 242 3. Form a synthetic RTP packet with the following contents: 244 * Header: The RTP header of the original packet with the 245 following modifications: 247 * The X bit is set to zero 249 * The header is truncated to remove any extensions (12 + 4 * CC 250 bytes) 252 * Payload: The RTP payload of the original packet 254 4. Apply the inner cryptographic algorithm to the RTP packet. 256 5. Replace the header of the protected RTP packet with the header of 257 the original packet, and append to the payload of the packet (1) 258 the authentication tag from the original transform, and (2) an 259 empty OHB (0x00). 261 6. Apply the outer cryptographic algorithm to the RTP packet. If 262 encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST 263 be used when encrypting the RTP packet using the outer 264 cryptographic key. 266 When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes 267 after the SRTP packet exactly like using EKT with any other SRTP 268 transform. 270 5.2. Relaying a Packet 272 The Media Distributor has the part of the key for the outer (hop-by- 273 hop), but it does not have the part of the key for the (end-to-end) 274 cryptographic algorithm. The cryptographic algorithm and key used to 275 decrypt a packet and any encrypted RTP header extensions would be the 276 same as those used in the endpoint's outer algorithm and key. 278 In order to modify a packet, the Media Distributor decrypts the 279 packet, modifies the packet, updates the OHB with any modifications 280 not already present in the OHB, and re-encrypts the packet using the 281 cryptographic using the outer (hop-by-hop) key. 283 1. Apply the outer (hop-by-hop) cryptographic algorithm to decrypt 284 the packet. If decrypting RTP header extensions hop-by-hop, then 285 [RFC6904] MUST be used. Note that the RTP payload produced by 286 this decryption operation contains the original encrypted payload 287 with the tag from the inner transform and the OHB appended. 289 2. Change any parts of the RTP packet that the relay wishes to 290 change and are allowed to be changed. 292 3. If a changed RTP header field is not already in the OHB, add it 293 with its original value to the OHB. A Media Distributor can add 294 information to the OHB, but MUST NOT change existing information 295 in the OHB. 297 4. If the Media Distributor resets a parameter to its original 298 value, it MAY drop it from the OHB. Note that this might result 299 in a decrease in the size of the OHB. 301 5. Apply the outer (hop-by-hop) cryptographic algorithm to the 302 packet. If the RTP Sequence Number has been modified, SRTP 303 processing happens as defined in SRTP and will end up using the 304 new Sequence Number. If encrypting RTP header extensions hop-by- 305 hop, then [RFC6904] MUST be used. 307 5.3. Decrypting a Packet 309 To decrypt a packet, the endpoint first decrypts and verifies using 310 the outer (hop-by-hop) cryptographic key, then uses the OHB to 311 reconstruct the original packet, which it decrypts and verifies with 312 the inner (end-to-end) cryptographic key. 314 1. Apply the outer cryptographic algorithm to the packet. If the 315 integrity check does not pass, discard the packet. The result of 316 this is referred to as the outer SRTP packet. If decrypting RTP 317 header extensions hop-by-hop, then [RFC6904] MUST be used when 318 decrypting the RTP packet using the outer cryptographic key. 320 2. If the packet is for repair mode data, skip the rest of the 321 steps. 323 3. Remove the inner authentication tag and the OHB from the end of 324 the payload of the outer SRTP packet. 326 4. Form a new synthetic SRTP packet with: 328 * Header = Received header, with the following modifications: 330 * Header fields replaced with values from OHB (if any) 332 * The X bit is set to zero 334 * The header is truncated to remove any extensions (12 + 4 * CC 335 bytes) 337 * Payload is the encrypted payload from the outer SRTP packet 338 (after the inner tag and OHB have been stripped). 340 * Authentication tag is the inner authentication tag from the 341 outer SRTP packet. 343 5. Apply the inner cryptographic algorithm to this synthetic SRTP 344 packet. Note if the RTP Sequence Number was changed by the Media 345 Distributor, the synthetic packet has the original Sequence 346 Number. If the integrity check does not pass, discard the 347 packet. 349 Once the packet has been successfully decrypted, the application 350 needs to be careful about which information it uses to get the 351 correct behaviour. The application MUST use only the information 352 found in the synthetic SRTP packet and MUST NOT use the other data 353 that was in the outer SRTP packet with the following exceptions: 355 o The PT from the outer SRTP packet is used for normal matching to 356 SDP and codec selection. 358 o The sequence number from the outer SRTP packet is used for normal 359 RTP ordering. 361 The PT and sequence number from the inner SRTP packet can be used for 362 collection of various statistics. 364 If any of the following RTP headers extensions are found in the outer 365 SRTP packet, they MAY be used: 367 o Mixer-to-client audio level indicators (See [RFC6465]) 369 6. RTCP Operations 371 Unlike RTP, which is encrypted both hop-by-hop and end-to-end using 372 two separate cryptographic key, RTCP is encrypted using only the 373 outer (hop-by-hop) cryptographic key. The procedures for RTCP 374 encryption are specified in [RFC3711] and this document introduces no 375 additional steps. 377 7. Use with Other RTP Mechanisms 379 There are some RTP related extensions that need special consideration 380 to be used by a relay when using the double transform due to the end- 381 to-end protection of the RTP. The repair mechanism, when used with 382 double, typically operate on the double encrypted data then take the 383 results of theses operations and encrypted them using only the HBH 384 key. This results in three cryptography operation happening to the 385 repair data sent over the wire. 387 7.1. RTX 389 When using RTX [RFC4588] with double, the cached payloads MUST be the 390 encrypted packets with the bits that are sent over the wire to the 391 other side. When encrypting a retransmission packet, it MUST be 392 encrypted in repair mode packet. 394 7.2. RED 396 TODO - Add text to explain how to use RED as described in Option A of 397 slides presented at IETF 99. 399 7.3. FEC 401 When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with 402 double, the negotiation of double for the crypto is the out of band 403 signaling that indicates that the repair packets MUST use the order 404 of operations of SRTP followed by FEC when encrypting. This is to 405 ensure that the original media is not reveled to the Media 406 Distributor but at the same time allow the Media Distributor to 407 repair media. When encrypting a packet that contains the Flex FEC 408 data, which is already encrypted, it MUST be encrypted in repair mode 409 packet. 411 The algorithm recommend in [I-D.ietf-rtcweb-fec] for repair of video 412 is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that for 413 interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends not 414 using additional FEC only m-line in SDP for the repair packets. 416 7.4. DTMF 418 When DTMF is sent with [RFC4733], it is end-to-end encrypted and the 419 relay can not read it so it can not be used to controll the relay. 420 Other out of band methods to controll the relay need to be used 421 instead. 423 8. Recommended Inner and Outer Cryptographic Algorithms 425 This specification recommends and defines AES-GCM as both the inner 426 and outer cryptographic algorithms, identified as 427 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 428 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithm provide 429 for authenticated encryption and will consume additional processing 430 time double-encrypting for hop-by-hop and end-to-end. However, the 431 approach is secure and simple, and is thus viewed as an acceptable 432 trade-off in processing efficiency. 434 Note that names for the cryptographic transforms are of the form 435 DOUBLE_(inner algorithm)_(outer algorithm). 437 While this document only defines a profile based on AES-GCM, it is 438 possible for future documents to define further profiles with 439 different inner and outer crypto in this same framework. For 440 example, if a new SRTP transform was defined that encrypts some or 441 all of the RTP header, it would be reasonable for systems to have the 442 option of using that for the outer algorithm. Similarly, if a new 443 transform was defined that provided only integrity, that would also 444 be reasonable to use for the hop-by-hop as the payload data is 445 already encrypted by the end-to-end. 447 The AES-GCM cryptographic algorithm introduces an additional 16 448 octets to the length of the packet. When using AES-GCM for both the 449 inner and outer cryptographic algorithms, the total additional length 450 is 32 octets. If no other header extensions are present in the 451 packet and the OHB is introduced, that will consume an additional 8 452 octets. If other extensions are already present, the OHB will 453 consume up to 4 additional octets. 455 9. Security Considerations 457 To summarize what is encrypted and authenticated, we will refer to 458 all the RTP fields and headers created by the sender and before the 459 pay load as the initial envelope and the RTP payload information with 460 the media as the payload. Any additional headers added by the Media 461 Distributor are referred to as the extra envelope. The sender uses 462 the end-to-end key to encrypts the payload and authenticate the 463 payload + initial envelope which using an AEAD cipher results in a 464 slight longer new payload. Then the sender uses the hop-by-hop key 465 to encrypt the new payload and authenticate the initial envelope and 466 new payload. 468 The Media Distributor has the hop-by-hop key so it can check the 469 authentication of the received packet across the initial envelope and 470 payload data but it can't decrypt the payload as it does not have the 471 end-to-end key. It can add extra envelope information. It then 472 authenticates the initial plus extra envelope information plus 473 payload with a hop-by-hop key. This hop-by-hop for the outgoing 474 packet is typically different than the hop-by-hop key for the 475 incoming packet. 477 The receiver can check the authentication of the initial and extra 478 envelope information. This, along with the OHB, is used to construct 479 a synthetic packet that is should be identical to one the sender 480 created and the receiver can check that it is identical and then 481 decrypt the original payload. 483 The end result is that if the authentications succeed, the receiver 484 knows exactly what the original sender sent, as well as exactly which 485 modifications were made by the Media Distributor. 487 It is obviously critical that the intermediary has only the outer 488 (hop-by-hop) algorithm key and not the half of the key for the the 489 inner (end-to-end) algorithm. We rely on an external key management 490 protocol to assure this property. 492 Modifications by the intermediary result in the recipient getting two 493 values for changed parameters (original and modified). The recipient 494 will have to choose which to use; there is risk in using either that 495 depends on the session setup. 497 The security properties for both the inner (end-to-end) and outer 498 (hop-by-hop) key holders are the same as the security properties of 499 classic SRTP. 501 10. IANA Considerations 503 10.1. RTP Header Extension 505 This document defines a new extension URI in the RTP Compact Header 506 Extensions part of the Real-Time Transport Protocol (RTP) Parameters 507 registry, according to the following data: 509 Extension URI: urn:ietf:params:rtp-hdrext:ohb 511 Description: Original Header Block 513 Contact: Cullen Jennings 515 Reference: RFCXXXX 517 Note to RFC Editor: Replace RFCXXXX with the RFC number of this 518 specification. 520 10.2. DTLS-SRTP 522 We request IANA to add the following values to defines a DTLS-SRTP 523 "SRTP Protection Profile" defined in [RFC5764]. 525 +------------+------------------------------------------+-----------+ 526 | Value | Profile | Reference | 527 +------------+------------------------------------------+-----------+ 528 | {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFCXXXX | 529 | 0x09} | | | 530 | {0x00, | DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM | RFCXXXX | 531 | 0x0A} | | | 532 +------------+------------------------------------------+-----------+ 534 Note to IANA: Please assign value RFCXXXX and update table to point 535 at this RFC for these values. 537 The SRTP transform parameters for each of these protection are: 539 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM 540 cipher: AES_128_GCM then AES_128_GCM 541 cipher_key_length: 256 bits 542 cipher_salt_length: 192 bits 543 aead_auth_tag_length: 32 octets 544 auth_function: NULL 545 auth_key_length: N/A 546 auth_tag_length: N/A 547 maximum lifetime: at most 2^31 SRTCP packets and 548 at most 2^48 SRTP packets 550 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM 551 cipher: AES_256_GCM then AES_256_GCM 552 cipher_key_length: 512 bits 553 cipher_salt_length: 192 bits 554 aead_auth_tag_length: 32 octets 555 auth_function: NULL 556 auth_key_length: N/A 557 auth_tag_length: N/A 558 maximum lifetime: at most 2^31 SRTCP packets and 559 at most 2^48 SRTP packets 561 The first half of the key and salt is used for the inner (end-to-end) 562 algorithm and the second half is used for the outer (hop-by-hop) 563 algorithm. 565 11. Acknowledgments 567 Many thanks to Richard Barnes for sending significant text for this 568 specification. Thank you for reviews and improvements from David 569 Benham, Paul Jones, Suhas Nandakumar, Nils Ohlmeier, and Magnus 570 Westerlund. 572 12. References 574 12.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 578 RFC2119, March 1997, 579 . 581 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 582 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 583 RFC 3711, DOI 10.17487/RFC3711, March 2004, 584 . 586 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 587 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 588 2008, . 590 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 591 Security (DTLS) Extension to Establish Keys for the Secure 592 Real-time Transport Protocol (SRTP)", RFC 5764, DOI 593 10.17487/RFC5764, May 2010, 594 . 596 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 597 Real-time Transport Protocol (SRTP)", RFC 6904, DOI 598 10.17487/RFC6904, April 2013, 599 . 601 [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 602 in the Secure Real-time Transport Protocol (SRTP)", RFC 603 7714, DOI 10.17487/RFC7714, December 2015, 604 . 606 12.2. Informative References 608 [I-D.ietf-payload-flexible-fec-scheme] 609 Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP 610 Payload Format for Flexible Forward Error Correction 611 (FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in 612 progress), July 2017. 614 [I-D.ietf-perc-dtls-tunnel] 615 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 616 between a Media Distributor and Key Distributor to 617 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-01 618 (work in progress), April 2017. 620 [I-D.ietf-perc-private-media-framework] 621 Jones, P., Benham, D., and C. Groves, "A Solution 622 Framework for Private Media in Privacy Enhanced RTP 623 Conferencing", draft-ietf-perc-private-media-framework-04 624 (work in progress), July 2017. 626 [I-D.ietf-perc-srtp-ekt-diet] 627 Jennings, C., Mattsson, J., McGrew, D., and D. Wing, 628 "Encrypted Key Transport for DTLS and Secure RTP", draft- 629 ietf-perc-srtp-ekt-diet-05 (work in progress), June 2017. 631 [I-D.ietf-rtcweb-fec] 632 Uberti, J., "WebRTC Forward Error Correction 633 Requirements", draft-ietf-rtcweb-fec-06 (work in 634 progress), July 2017. 636 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 637 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 638 DOI 10.17487/RFC4588, July 2006, 639 . 641 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 642 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 643 DOI 10.17487/RFC4733, December 2006, 644 . 646 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 647 time Transport Protocol (RTP) Header Extension for Mixer- 648 to-Client Audio Level Indication", RFC 6465, DOI 10.17487/ 649 RFC6465, December 2011, 650 . 652 Appendix A. Encryption Overview 654 The following figure shows a double encrypted SRTP packet. The sides 655 indicate the parts of the packet that are encrypted and authenticated 656 by the hob-by-hop and end-to-end operations. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ 661 |V=2|P|X| CC |M| PT | sequence number | I O 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I O 663 | timestamp | I O 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I O 665 | synchronization source (SSRC) identifier | I O 666 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ I O 667 | contributing source (CSRC) identifiers | I O 668 | .... | I O 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O 670 | RTP extension (OPTIONAL) ... | | O 671 +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O 672 O I | payload ... | I O 673 O I | +-------------------------------+ I O 674 O I | | RTP padding | RTP pad count | I O 675 O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ O 676 O | | E2E authentication tag | | O 677 O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | O 678 O | | OHB ... | | O 679 +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<+ 680 | | | HBH authentication tag | | | 681 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 682 | | | | 683 | +- E2E Encrypted Portion E2E Authenticated Portion ---+ | 684 | | 685 +--- HBH Encrypted Portion HBH Authenticated Portion -----+ 687 Authors' Addresses 689 Cullen Jennings 690 Cisco Systems 692 Email: fluffy@iii.ca 694 Paul E. Jones 695 Cisco Systems 697 Email: paulej@packetizer.com 699 Richard Barnes 700 Cisco Systems 702 Email: rlb@ipv.sx 703 Adam Roach 704 Mozilla 706 Email: adam@nostrum.com