idnits 2.17.1 draft-ietf-perc-double-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1747 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) == Outdated reference: A later version (-12) exists of draft-ietf-perc-dtls-tunnel-05 == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-09 == Outdated reference: A later version (-10) exists of draft-ietf-rtcweb-fec-09 Summary: 0 errors (**), 0 flaws (~~), 4 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: January 9, 2020 Cisco Systems 6 A. Roach 7 Mozilla 8 July 8, 2019 10 SRTP Double Encryption Procedures 11 draft-ietf-perc-double-11 13 Abstract 15 In some conferencing scenarios, it is desirable for an intermediary 16 to be able to manipulate some parameters in Real Time Protocol (RTP) 17 packets, while still providing strong end-to-end security guarantees. 18 This document defines a cryptographic transform for the Secure Real 19 Time Protocol (SRTP) that uses two separate but related cryptographic 20 operations to provide hop-by-hop and end-to-end security guarantees. 21 Both the end-to-end and hop-by-hop cryptographic algorithms can 22 utilize an authenticated encryption with associated data (AEAD) 23 algorithm or take advantage of future SRTP transforms with different 24 properties. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Cryptographic Context . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 5 64 4. Original Header Block . . . . . . . . . . . . . . . . . . . . 5 65 5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 7 67 5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 8 68 5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 9 69 6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 10 70 7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 10 71 7.1. RTP Retransmission (RTX) . . . . . . . . . . . . . . . . 11 72 7.2. Redundant Audio Data (RED) . . . . . . . . . . . . . . . 11 73 7.3. Forward Error Correction (FEC) . . . . . . . . . . . . . 12 74 7.4. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. Recommended Inner and Outer Cryptographic Algorithms . . . . 12 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 10.1. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . 14 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 12.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Appendix A. Encryption Overview . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 Cloud conferencing systems that are based on switched conferencing 89 have a central Media Distributor device that receives media from 90 endpoints and distributes it to other endpoints, but does not need to 91 interpret or change the media content. For these systems, it is 92 desirable to have one cryptographic key that enables encryption and 93 authentication of the media end-to-end while still allowing certain 94 information in the header of a Real Time Protocol (RTP) packet to be 95 changed by the Media Distributor. At the same time, a separate 96 cryptographic key provides integrity and optional confidentiality for 97 the media flowing between the Media Distributor and the endpoints. 98 The framework document [I-D.ietf-perc-private-media-framework] 99 describes this concept in more detail. 101 This specification defines a transform for the Secure Real Time 102 Protocol (SRTP) that uses the AES-GCM algorithm [RFC7714] to provide 103 encryption and integrity for an RTP packet for the end-to-end 104 cryptographic key as well as a hop-by-hop cryptographic encryption 105 and integrity between the endpoint and the Media Distributor. The 106 Media Distributor decrypts and checks integrity of the hop-by-hop 107 security. The Media Distributor MAY change some of the RTP header 108 information that would impact the end-to-end integrity. In that 109 case, the original value of any RTP header field that is changed is 110 included in an "Original Header Block" that is added to the packet. 111 The new RTP packet is encrypted with the hop-by-hop cryptographic 112 algorithm before it is sent. The receiving endpoint decrypts and 113 checks integrity using the hop-by-hop cryptographic algorithm and 114 then replaces any parameters the Media Distributor changed using the 115 information in the Original Header Block before decrypting and 116 checking the end-to-end integrity. 118 One can think of the double as a normal SRTP transform for encrypting 119 the RTP in a way where things that only know half of the key, can 120 decrypt and modify part of the RTP packet but not other parts, 121 including the media payload. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 Terms used throughout this document include: 133 o Media Distributor: A device that receives media from endpoints and 134 distributes it to other endpoints, but does not need to interpret 135 or change the media content (see also 136 [I-D.ietf-perc-private-media-framework]) 138 o end-to-end: The path from one endpoint through one or more Media 139 Distributors to the endpoint at the other end. 141 o hop-by-hop: The path from the endpoint to or from the Media 142 Distributor. 144 o Original Header Block (OHB): An octet string that contains the 145 original values from the RTP header that might have been changed 146 by a Media Distributor. 148 3. Cryptographic Context 150 This specification uses a cryptographic context with two parts: 152 o An inner (end-to-end) part that is used by endpoints that 153 originate and consume media to ensure the integrity of media end- 154 to-end, and 156 o An outer (hop-by-hop) part that is used between endpoints and 157 Media Distributors to ensure the integrity of media over a single 158 hop and to enable a Media Distributor to modify certain RTP header 159 fields. RTCP is also handled using the hop-by-hop cryptographic 160 part. 162 The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is 163 AES-GCM. Other combinations of SRTP ciphers that support the 164 procedures in this document can be added to the IANA registry. 166 The keys and salt for these algorithms are generated with the 167 following steps: 169 o Generate key and salt values of the length required for the 170 combined inner (end-to-end) and outer (hop-by-hop) algorithms. 172 o Assign the key and salt values generated for the inner (end-to- 173 end) algorithm to the first half of the key and the first half of 174 the salt for the double algorithm. 176 o Assign the key and salt values for the outer (hop-by-hop) 177 algorithm to the second half of the key and second half of the 178 salt for the double algorithm. The first half of the key is 179 referred to as the inner key while the second half is referred to 180 as the outer key. When a key is used by a cryptographic 181 algorithm, the salt used is the part of the salt generated with 182 that key. 184 o the SSRC is the same for both the inner and out outer algorithms 185 as it can not be changed. 187 o The SEQ and ROC are tracked independently for the inner and outer 188 algorithms. 190 If the Media Distributor is to be able to modify header fields but 191 not decrypt the payload, then it must have cryptographic key for the 192 outer algorithm, but not the inner (end-to-end) algorithm. This 193 document does not define how the Media Distributor should be 194 provisioned with this information. One possible way to provide 195 keying material for the outer (hop-by-hop) algorithm is to use 196 [I-D.ietf-perc-dtls-tunnel]. 198 3.1. Key Derivation 200 Although SRTP uses a single master key to derive keys for an SRTP 201 session, this transform requires separate inner and outer keys. In 202 order to allow the inner and outer keys to be managed independently 203 via the master key, the transforms defined in this document MUST be 204 used with the following pseudo-random function (PRF), which preserves 205 the separation between the two halves of the key. Given a positive 206 integer "n" representing the desired output length, a master key 207 "k_master", and an input "x": 209 PRF\_double\_n(k\_master,x) = PRF\_(n/2)(inner(k\_master),x) || 210 PRF\_(n/2)(outer(k\_master),x) 212 Here "PRF_n(k, x)" represents the AES_CM PRF KDF (see Section 4.3.3 213 of [RFC3711]) for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm 214 and AES_256_CM_PRF KDF [RFC6188] for 215 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm. "inner(key)" 216 represents the first half of the key, and "outer(key)" represents the 217 second half of the key. 219 4. Original Header Block 221 The Original Header Block (OHB) contains the original values of any 222 modified RTP header fields. In the encryption process, the OHB is 223 included in an SRTP packet as described in Section 5. In the 224 decryption process, the receiving endpoint uses it to reconstruct the 225 original RTP header, so that it can pass the proper AAD value to the 226 inner transform. 228 The OHB can reflect modifications to the following fields in an RTP 229 header: the payload type, the sequence number, and the marker bit. 230 All other fields in the RTP header MUST remain unmodified; since the 231 OHB cannot reflect their original values, the receiver will be unable 232 to verify the E2E integrity of the packet. 234 The OHB has the following syntax (in ABNF [RFC5234]): 236 OCTET = %x00-FF 238 PT = OCTET 239 SEQ = 2OCTET 240 Config = OCTET 241 OHB = [ PT ] [ SEQ ] Config 243 If present, the PT and SEQ parts of the OHB contain the original 244 payload type and sequence number fields, respectively. The final 245 "config" octet of the OHB specifies whether these fields are present, 246 and the original value of the marker bit (if necessary): 248 +-+-+-+-+-+-+-+-+ 249 |R R R R B M P Q| 250 +-+-+-+-+-+-+-+-+ 252 o P: PT is present 254 o Q: SEQ is present 256 o M: Marker bit is present 258 o B: Value of marker bit 260 o R: Reserved, MUST be set to 0 262 In particular, an all-zero OHB config octet (0x00) indicates that 263 there have been no modifications from the original header. 265 If the marker bit is not present (M=0), then B MUST be set to zero. 266 That is, if "C" represents the value of the config octet, then the 267 masked value "C & 0x0C" MUST NOT have the value "0x80". 269 5. RTP Operations 271 As implied by the use of the word "double" above, this transform 272 applies AES-GCM to the SRTP packet twice. This allows media 273 distributors to be able to modify some header fields while allowing 274 endpoints to verify the end-to-end integrity of a packet. 276 The first, "inner" application of AES-GCM encrypts the SRTP payload 277 and integrity-protects a version of the SRTP header with extensions 278 truncated. Omitting extensions from the inner integrity check means 279 that they can be modified by a media distributor holding only the 280 "outer" key. 282 The second, "outer" application of AES-GCM encrypts the ciphertext 283 produced by the inner encryption (i.e., the encrypted payload and 284 authentication tag), plus an OHB that expresses any changes made 285 between the inner and outer transforms. 287 A media distributor that has the outer key but not the inner key may 288 modify the header fields that can be included in the OHB by 289 decrypting, modifying, and re-encrypting the packet. 291 5.1. Encrypting a Packet 293 To encrypt a packet, the endpoint encrypts the packet using the inner 294 (end-to-end) cryptographic key and then encrypts using the outer 295 (hop-by-hop) cryptographic key. The encryption also supports a mode 296 for repair packets that only does the outer (hop-by-hop) encryption. 297 The processes is as follows: 299 1. Form an RTP packet. If there are any header extensions, they 300 MUST use [RFC8285]. 302 2. If the packet is for repair mode data, skip to step 6. 304 3. Form a synthetic RTP packet with the following contents: 306 * Header: The RTP header of the original packet with the 307 following modifications: 309 * The X bit is set to zero 311 * The header is truncated to remove any extensions (i.e., keep 312 only the first 12 + 4 * CC bytes of the header) 314 * Payload: The RTP payload of the original packet 316 4. Apply the inner cryptographic algorithm to the synthetic RTP 317 packet from the previous step. 319 5. Replace the header of the protected RTP packet with the header of 320 the original packet (to restore any header extensions and reset 321 the X bit), and append an empty OHB (0x00) to the encrypted 322 payload (with the authentication tag) obtained from the step 4. 324 6. Apply the outer cryptographic algorithm to the RTP packet. If 325 encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST 326 be used when encrypting the RTP packet using the outer 327 cryptographic key. 329 When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes 330 after the SRTP packet exactly like using EKT with any other SRTP 331 transform. 333 5.2. Relaying a Packet 335 The Media Distributor has the part of the key for the outer (hop-by- 336 hop) cryptographic algorithm, but it does not have the part of the 337 key for the (end-to-end) cryptographic algorithm. The cryptographic 338 algorithm and key used to decrypt a packet and any encrypted RTP 339 header extensions would be the same as those used in the endpoint's 340 outer algorithm and key. 342 In order to modify a packet, the Media Distributor decrypts the 343 received packet, modifies the packet, updates the OHB with any 344 modifications not already present in the OHB, and re-encrypts the 345 packet using the the outer (hop-by-hop) cryptographic key before 346 transmitting. 348 1. Apply the outer (hop-by-hop) cryptographic algorithm to decrypt 349 the packet. If decrypting RTP header extensions hop-by-hop, then 350 [RFC6904] MUST be used. Note that the RTP payload produced by 351 this decryption operation contains the original encrypted payload 352 with the tag from the inner transform and the OHB appended. 354 2. Make any desired changes to the fields are allowed to be changed, 355 i.e., PT, SEQ, and M. The Media Distributor MAY also make 356 modifications to header extensions, without the need to reflect 357 these changes in the OHB. 359 3. Reflect any changes to header fields in the OHB: 361 * If Media Distributor changed a field that is not already in 362 the OHB, then it MUST add the original value of the field to 363 the OHB. Note that this might result in an increase in the 364 size of the OHB. 366 * If the Media Distributor took a field that had previously been 367 modified and reset to its original value, then it SHOULD drop 368 the corresponding information from the OHB. Note that this 369 might result in a decrease in the size of the OHB. 371 * Otherwise, the Media Distributor MUST NOT modify the OHB. 373 4. Apply the outer (hop-by-hop) cryptographic algorithm to the 374 packet. If the RTP Sequence Number has been modified, SRTP 375 processing happens as defined in SRTP and will end up using the 376 new Sequence Number. If encrypting RTP header extensions hop-by- 377 hop, then [RFC6904] MUST be used. 379 In order to avoid nonce reuse, the cryptographic contexts used in 380 step 1 and step 5 MUST use different, independent master keys. Note 381 that this means that the key used for decryption by the MD MUST be 382 different from the key used for re-encryption to the end recipient. 384 Note that if multiple MDs modify the same packet, then the first MD 385 to alter a given header field is the one that adds it to the OHB. If 386 a subsequent MD changes the value of a header field that has already 387 been changed, then the original value will already be in the OHB, so 388 no update to the OHB is required. 390 A Media Distributor that decrypts, modifies, and re-encrypts packets 391 in this way MUST use an independent key for each recipient, and MUST 392 NOT re-encrypt the packet using the sender's keys. If the Media 393 Distributor decrypts and re-encrypts with the same key and salt, it 394 will result in the reuse of a (key, nonce) pair, undermining the 395 security of AES-GCM. 397 5.3. Decrypting a Packet 399 To decrypt a packet, the endpoint first decrypts and verifies using 400 the outer (hop-by-hop) cryptographic key, then uses the OHB to 401 reconstruct the original packet, which it decrypts and verifies with 402 the inner (end-to-end) cryptographic key. 404 1. Apply the outer cryptographic algorithm to the packet. If the 405 integrity check does not pass, discard the packet. The result of 406 this is referred to as the outer SRTP packet. If decrypting RTP 407 header extensions hop-by-hop, then [RFC6904] MUST be used when 408 decrypting the RTP packet using the outer cryptographic key. 410 2. If the packet is for repair mode data, skip the rest of the 411 steps. Note that the packet that results from the repair 412 algorithm will still have encrypted data that needs to be 413 decrypted as specified by the repair algorithm sections. 415 3. Remove the inner authentication tag and the OHB from the end of 416 the payload of the outer SRTP packet. 418 4. Form a new synthetic SRTP packet with: 420 * Header = Received header, with the following modifications: 422 * Header fields replaced with values from OHB (if any) 424 * The X bit is set to zero 426 * The header is truncated to remove any extensions (i.e., keep 427 only the first 12 + 4 * CC bytes of the header) 429 * Payload is the encrypted payload from the outer SRTP packet 430 (after the inner tag and OHB have been stripped). 432 * Authentication tag is the inner authentication tag from the 433 outer SRTP packet. 435 5. Apply the inner cryptographic algorithm to this synthetic SRTP 436 packet. Note if the RTP Sequence Number was changed by the Media 437 Distributor, the synthetic packet has the original Sequence 438 Number. If the integrity check does not pass, discard the 439 packet. 441 Once the packet has been successfully decrypted, the application 442 needs to be careful about which information it uses to get the 443 correct behavior. The application MUST use only the information 444 found in the synthetic SRTP packet and MUST NOT use the other data 445 that was in the outer SRTP packet with the following exceptions: 447 o The PT from the outer SRTP packet is used for normal matching to 448 SDP and codec selection. 450 o The sequence number from the outer SRTP packet is used for normal 451 RTP ordering. 453 The PT and sequence number from the inner SRTP packet can be used for 454 collection of various statistics. 456 If the RTP header of the outer packet contains extensions, they MAY 457 be used. However, because extensions are not protected end-to-end, 458 implementations SHOULD reject an RTP packet containing headers that 459 would require end-to-end protection. 461 6. RTCP Operations 463 Unlike RTP, which is encrypted both hop-by-hop and end-to-end using 464 two separate cryptographic keys, RTCP is encrypted using only the 465 outer (hop-by-hop) cryptographic key. The procedures for RTCP 466 encryption are specified in [RFC3711] and this document introduces no 467 additional steps. 469 7. Use with Other RTP Mechanisms 471 Media Distributors sometimes interact with RTP media packets sent by 472 endpoints, e.g., to provide recovery or receive commands via DTMF. 473 When media packets are encrypted end-to-end, these procedures require 474 modification. (End-to-end interactions, including end-to-end 475 recovery, are not affected by end-to-end encryption.) 476 Repair mechanisms, in general, will need to perform recovery on 477 encrypted packets (double-encrypted when using this transform), since 478 the Media Distributor does not have access to the plaintext of the 479 packet, only an intermediate, E2E-encrypted form. 481 When the recovery mechanism calls for the recovery packet itself to 482 be encrypted, it is encrypted with only the outer, hop-by-hop key. 483 This allows a media distributor to generate recovery packets without 484 having access to the inner, end-to-end keys. However, it also 485 results in recovery packets being triple-encrypted, twice for the 486 base transform, and once for the recovery protection. 488 7.1. RTP Retransmission (RTX) 490 When using RTX [RFC4588] with double, the cached payloads MUST be the 491 double-encrypted packets, i.e., the bits that are sent over the wire 492 to the other side. When encrypting a retransmission packet, it MUST 493 be encrypted the packet in repair mode (i.e., with only the hop-by- 494 hop key). 496 If the Media Distributor were to cache the inner, E2E-encrypted 497 payload and retransmit that with an RTX OSN field prepended, then the 498 modifications to the payload would cause the inner integrity check to 499 fail at the receiver. 501 A typical RTX receiver would decrypt the packet, undo the RTX 502 transformation, then process the resulting packet normally by using 503 the steps in Section 5.3. 505 7.2. Redundant Audio Data (RED) 507 When using RED [RFC2198] with double, the processing at the sender 508 and receiver is the same as when using RED with any other SRTP 509 transform. 511 The main difference between double and any other transform is that in 512 an intermediated environment, usage of RED must be end-to-end. A 513 Media Distributor cannot synthesize RED packets, because it lacks 514 access to the plaintext media payloads that are combined to form a 515 RED payload. 517 Note that FlexFEC may often provide similar or better repair 518 capabilities compared to RED. For most applications, FlexFEC is a 519 better choice than RED; in particular, FlexFEC has modes in which the 520 Media Distributor can synthesize recovery packets. 522 7.3. Forward Error Correction (FEC) 524 When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with 525 double, repair packets MUST be constructed by first double-encrypting 526 the packet, then performing FEC. Processing of repair packets 527 proceeds in the opposite order, performing FEC recovery and then 528 decrypting. This ensures that the original media is not revealed to 529 the Media Distributor but at the same time allows the Media 530 Distributor to repair media. When encrypting a packet that contains 531 the Flex FEC data, which is already encrypted, it MUST be encrypted 532 with only the outer, hop-by-hop transform. 534 The algorithm recommended in [I-D.ietf-rtcweb-fec] for repair of 535 video is Flex FEC [I-D.ietf-payload-flexible-fec-scheme]. Note that 536 for interoperability with WebRTC, [I-D.ietf-rtcweb-fec] recommends 537 not using additional FEC only m-line in SDP for the repair packets. 539 7.4. DTMF 541 When DTMF is sent using the mechanism in [RFC4733], it is end-to-end 542 encrypted and the relay can not read it, so it cannot be used to 543 control the relay. Other out of band methods to control the relay 544 need to be used instead. 546 8. Recommended Inner and Outer Cryptographic Algorithms 548 This specification recommends and defines AES-GCM as both the inner 549 and outer cryptographic algorithms, identified as 550 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 551 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithm provide 552 for authenticated encryption and will consume additional processing 553 time double-encrypting for hop-by-hop and end-to-end. However, the 554 approach is secure and simple, and is thus viewed as an acceptable 555 trade-off in processing efficiency. 557 Note that names for the cryptographic transforms are of the form 558 DOUBLE_(inner algorithm)_(outer algorithm). 560 While this document only defines a profile based on AES-GCM, it is 561 possible for future documents to define further profiles with 562 different inner and outer algorithms in this same framework. For 563 example, if a new SRTP transform was defined that encrypts some or 564 all of the RTP header, it would be reasonable for systems to have the 565 option of using that for the outer algorithm. Similarly, if a new 566 transform was defined that provided only integrity, that would also 567 be reasonable to use for the outer transform as the payload data is 568 already encrypted by the inner transform. 570 The AES-GCM cryptographic algorithm introduces an additional 16 571 octets to the length of the packet. When using AES-GCM for both the 572 inner and outer cryptographic algorithms, the total additional length 573 is 32 octets. The OHB will consume an additional 1-4 octets. 574 Packets in repair mode will carry additional repair data, further 575 increasing their size. 577 9. Security Considerations 579 This SRTP transform provides protection against two classes of 580 attacker: An network attacker that knows neither the inner nor outer 581 keys, and a malicious MD that knows the outer key. Obviously, it 582 provides no protections against an attacker that holds both the inner 583 and outer keys. 585 The protections with regard to the network are the same as with the 586 normal SRTP AES-GCM transforms. The major difference is that the 587 double transforms are designed to work better in a group context. In 588 such contexts, it is important to note that because these transforms 589 are symmetric, they do not protect against attacks within the group. 590 Any member of the group can generate valid SRTP packets for any SSRC 591 in use by the group. 593 With regard to a malicious MD, the recipient can verify the integrity 594 of the base header fields and confidentiality and integrity of the 595 payload. The recipient has no assurance, however, of the integrity 596 of the header extensions in the packet. 598 The main innovation of this transform relative to other SRTP 599 transforms is that it allows a partly-trusted MD to decrypt, modify, 600 and re-encrypt a packet. When this is done, the cryptographic 601 contexts used for decryption and re-encryption MUST use different, 602 independent master keys. If the same context is used, the nonce 603 formation rules for SRTP will cause the same key and nonce to be used 604 with two different plaintexts, which substantially degrades the 605 security of AES-GCM. 607 In other words, from the perspective of the MD, re-encrypting packets 608 using this protocol will involve the same cryptographic operations as 609 if it had established independent AES-GCM crypto contexts with the 610 sender and the receiver. If the MD doesn't modify any header fields, 611 then an MD that supports AES-GCM could be unused unmodified. 613 10. IANA Considerations 614 10.1. DTLS-SRTP 616 We request IANA to add the following values to defines a DTLS-SRTP 617 "SRTP Protection Profile" defined in [RFC5764]. 619 +------------+------------------------------------------+-----------+ 620 | Value | Profile | Reference | 621 +------------+------------------------------------------+-----------+ 622 | {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFCXXXX | 623 | 0x09} | | | 624 | {0x00, | DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM | RFCXXXX | 625 | 0x0A} | | | 626 +------------+------------------------------------------+-----------+ 628 Note to IANA: Please assign value RFCXXXX and update table to point 629 at this RFC for these values. 631 The SRTP transform parameters for each of these protection are: 633 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM 634 cipher: AES_128_GCM then AES_128_GCM 635 cipher_key_length: 256 bits 636 cipher_salt_length: 192 bits 637 aead_auth_tag_length: 256 bits 638 auth_function: NULL 639 auth_key_length: N/A 640 auth_tag_length: N/A 641 maximum lifetime: at most 2^31 SRTCP packets and 642 at most 2^48 SRTP packets 644 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM 645 cipher: AES_256_GCM then AES_256_GCM 646 cipher_key_length: 512 bits 647 cipher_salt_length: 192 bits 648 aead_auth_tag_length: 256 bits 649 auth_function: NULL 650 auth_key_length: N/A 651 auth_tag_length: N/A 652 maximum lifetime: at most 2^31 SRTCP packets and 653 at most 2^48 SRTP packets 655 The first half of the key and salt is used for the inner (end-to-end) 656 algorithm and the second half is used for the outer (hop-by-hop) 657 algorithm. 659 11. Acknowledgments 661 Thank you for reviews and improvements to this specification from 662 Alex Gouaillard, David Benham, Magnus Westerlund, Nils Ohlmeier, Paul 663 Jones, Roni Even, and Suhas Nandakumar. In addition, thank you to 664 Sergio Garcia Murillo proposed the change of transporting the OHB 665 information in the RTP payload instead of the RTP header. 667 12. References 669 12.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 677 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 678 RFC 3711, DOI 10.17487/RFC3711, March 2004, 679 . 681 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 682 Security (DTLS) Extension to Establish Keys for the Secure 683 Real-time Transport Protocol (SRTP)", RFC 5764, 684 DOI 10.17487/RFC5764, May 2010, 685 . 687 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 688 RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011, 689 . 691 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 692 Real-time Transport Protocol (SRTP)", RFC 6904, 693 DOI 10.17487/RFC6904, April 2013, 694 . 696 [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 697 in the Secure Real-time Transport Protocol (SRTP)", 698 RFC 7714, DOI 10.17487/RFC7714, December 2015, 699 . 701 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 702 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 703 May 2017, . 705 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 706 Mechanism for RTP Header Extensions", RFC 8285, 707 DOI 10.17487/RFC8285, October 2017, 708 . 710 12.2. Informative References 712 [I-D.ietf-payload-flexible-fec-scheme] 713 Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP 714 Payload Format for Flexible Forward Error Correction 715 (FEC)", draft-ietf-payload-flexible-fec-scheme-20 (work in 716 progress), May 2019. 718 [I-D.ietf-perc-dtls-tunnel] 719 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 720 between a Media Distributor and Key Distributor to 721 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05 722 (work in progress), April 2019. 724 [I-D.ietf-perc-private-media-framework] 725 Jones, P., Benham, D., and C. Groves, "A Solution 726 Framework for Private Media in Privacy Enhanced RTP 727 Conferencing (PERC)", draft-ietf-perc-private-media- 728 framework-12 (work in progress), June 2019. 730 [I-D.ietf-perc-srtp-ekt-diet] 731 Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. 732 Andreasen, "Encrypted Key Transport for DTLS and Secure 733 RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress), 734 October 2018. 736 [I-D.ietf-rtcweb-fec] 737 Uberti, J., "WebRTC Forward Error Correction 738 Requirements", draft-ietf-rtcweb-fec-09 (work in 739 progress), July 2019. 741 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 742 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 743 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 744 DOI 10.17487/RFC2198, September 1997, 745 . 747 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 748 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 749 DOI 10.17487/RFC4588, July 2006, 750 . 752 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 753 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 754 DOI 10.17487/RFC4733, December 2006, 755 . 757 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 758 Specifications: ABNF", STD 68, RFC 5234, 759 DOI 10.17487/RFC5234, January 2008, 760 . 762 Appendix A. Encryption Overview 764 The following figure shows a double encrypted SRTP packet. The sides 765 indicate the parts of the packet that are encrypted and authenticated 766 by the hop-by-hop and end-to-end operations. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++ 771 |V=2|P|X| CC |M| PT | sequence number | IO 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 773 | timestamp | IO 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO 775 | synchronization source (SSRC) identifier | IO 776 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO 777 | contributing source (CSRC) identifiers | IO 778 | .... | IO 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 780 | RTP extension (OPTIONAL) ... | |O 781 +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 782 O I | payload ... | IO 783 O I | +-------------------------------+ IO 784 O I | | RTP padding | RTP pad count | IO 785 O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O 786 O | | E2E authentication tag | |O 787 O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O 788 O | | OHB ... | |O 789 +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ 790 | | | HBH authentication tag | || 791 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || 792 | | || 793 | +- E2E Encrypted Portion E2E Authenticated Portion ---+| 794 | | 795 +--- HBH Encrypted Portion HBH Authenticated Portion ----+ 796 Authors' Addresses 798 Cullen Jennings 799 Cisco Systems 801 Email: fluffy@iii.ca 803 Paul E. Jones 804 Cisco Systems 806 Email: paulej@packetizer.com 808 Richard Barnes 809 Cisco Systems 811 Email: rlb@ipv.sx 813 Adam Roach 814 Mozilla 816 Email: adam@nostrum.com