idnits 2.17.1 draft-ietf-perc-double-05.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 (June 29, 2017) is 2464 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-04 == 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-03 == Outdated reference: A later version (-13) exists of draft-ietf-perc-srtp-ekt-diet-04 == Outdated reference: A later version (-10) exists of draft-ietf-rtcweb-fec-05 Summary: 1 error (**), 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 Cisco Systems 5 Expires: December 31, 2017 A. Roach 6 Mozilla 7 June 29, 2017 9 SRTP Double Encryption Procedures 10 draft-ietf-perc-double-05 12 Abstract 14 In some conferencing scenarios, it is desirable for an intermediary 15 to be able to manipulate some RTP parameters, while still providing 16 strong end-to-end security guarantees. This document defines SRTP 17 procedures that use two separate but related cryptographic operations 18 to provide hop-by-hop and end-to-end security guarantees. Both the 19 end-to-end and hop-by-hop cryptographic algorithms can utilize an 20 authenticated encryption with associated data scheme or take 21 advantage of future SRTP transforms with different properties. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 31, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Cryptographic Context . . . . . . . . . . . . . . . . . . . . 3 60 4. Original Header Block . . . . . . . . . . . . . . . . . . . . 4 61 5. RTP Operations . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 6 63 5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6 64 5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 8 65 6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. Use with Other RTP Mechanisms . . . . . . . . . . . . . . . . 9 67 7.1. RTX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.2. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.3. FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. Recommended Inner and Outer Cryptographic Algorithms . . . . 10 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 10.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 11 74 10.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . 12 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 12.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Cloud conferencing systems that are based on switched conferencing 84 have a central Media Distributor device that receives media from 85 endpoints and distributes it to other endpoints, but does not need to 86 interpret or change the media content. For these systems, it is 87 desirable to have one cryptographic key from the sending endpoint to 88 the receiving endpoint that can encrypt and authenticate the media 89 end-to-end while still allowing certain RTP header information to be 90 changed by the Media Distributor. At the same time, a separate 91 cryptographic key provides integrity and optional confidentiality for 92 the media flowing between the Media Distributor and the endpoints. 93 See the framework document that describes this concept in more detail 94 in more detail in [I-D.ietf-perc-private-media-framework]. 96 This specification defines an SRTP transform that uses the AES-GCM 97 algorithm [RFC7714] to provide encryption and integrity for an RTP 98 packet for the end-to-end cryptographic key as well as a hop-by-hop 99 cryptographic encryption and integrity between the endpoint and the 100 Media Distributor. The Media Distributor decrypts and checks 101 integrity of the hop-by-hop security. The Media Distributor MAY 102 change some of the RTP header information that would impact the end- 103 to-end integrity. The original value of any RTP header field that is 104 changed is included in a new RTP header extension called the Original 105 Header Block. The new RTP packet is encrypted with the hop-by-hop 106 cryptographic algorithm before it is sent. The receiving endpoint 107 decrypts and checks integrity using the hop-by-hop cryptographic 108 algorithm and then replaces any parameters the Media Distributor 109 changed using the information in the Original Header Block before 110 decrypting and checking the end-to-end integrity. 112 One can think of the double as a normal SRTP transform for encrypting 113 the RTP in a way where things that only know half of the key, can 114 decrypt and modify part of the RTP packet but not other parts of if 115 including the media payload. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 Terms used throughout this document include: 125 o Media Distributor: media distribution device that routes media 126 from one endpoint to other endpoints 128 o end-to-end: meaning the link from one endpoint through one or more 129 Media Distributors to the endpoint at the other end. 131 o hop-by-hop: meaning the link from the endpoint to or from the 132 Media Distributor. 134 o OHB: Original Header Block is an RTP header extension that 135 contains the original values from the RTP header that might have 136 been changed by a Media Distributor. 138 3. Cryptographic Context 140 This specification uses a cryptographic context with two parts: an 141 inner (end-to-end) part that is used by endpoints that originate and 142 consume media to ensure the integrity of media end-to-end, and an 143 outer (hop-by-hop) part that is used between endpoints and Media 144 Distributors to ensure the integrity of media over a single hop and 145 to enable a Media Distributor to modify certain RTP header fields. 146 RTCP is also handled using the hop-by-hop cryptographic part. The 147 RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is 148 AES-GCM. Other combinations of SRTP ciphers that support the 149 procedures in this document can be added to the IANA registry. 151 The keys and salt for these algorithms are generated with the 152 following steps: 154 o Generate key and salt values of the length required for the 155 combined inner (end-to-end) and outer (hop-by-hop) algorithms. 157 o Assign the key and salt values generated for the inner (end-to- 158 end) algorithm to the first half of the key and salt for the 159 double algorithm. 161 o Assign the key and salt values for the outer (hop-by-hop) 162 algorithm to the second half of the key and salt for the double 163 algorithm. The first half of the key is revered to as the inner 164 key while the second out half is referred to as the outer key. 165 When a key is used by a cryptographic algorithm, the salt used is 166 the part of the salt generated with that key. 168 Obviously, if the Media Distributor is to be able to modify header 169 fields but not decrypt the payload, then it must have cryptographic 170 key for the outer algorithm, but not the inner (end-to-end) 171 algorithm. This document does not define how the Media Distributor 172 should be provisioned with this information. One possible way to 173 provide keying material for the outer (hop-by-hop) algorithm is to 174 use [I-D.ietf-perc-dtls-tunnel]. 176 4. Original Header Block 178 Any SRTP packet processed following these procedures MAY contain an 179 Original Header Block (OHB) RTP header extension. 181 The OHB contains the original values of any modified header fields 182 and MUST be placed after any already-existing RTP header extensions. 183 Placement of the OHB after any original header extensions is 184 important so that the receiving endpoint can properly authenticate 185 the original packet and any originally included RTP header 186 extensions. The receiving endpoint will authenticate the original 187 packet by restoring the modified RTP header field values and header 188 extensions. It does this by copying the original values from the OHB 189 and then removing the OHB extension and any other RTP header 190 extensions that appear after the OHB extension. 192 The Media Distributor is only permitted to modify the extension (X) 193 bit, payload type (PT) field, and the RTP sequence number field. 195 The OHB extension is either one octet in length, two octets in 196 length, or three octets in length. The length of the OHB indicates 197 what data is contained in the extension. 199 If the OHB is one octet in length, it contains the original PT field 200 value. In this case, the OHB has this form: 202 0 1 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 204 +-+-+-+-+-+-+-+-+---------------+ 205 | ID | len=0 |R| PT | 206 +-+-+-+-+-+-+-+-+---------------+ 208 Note that "R" indicates a reserved bit that MUST be set to zero when 209 sending a packet and ignored upon receipt. ID is the RTP Header 210 Extension identifier negotiated in the SDP. 212 If the OHB is two octets in length, it contains the original RTP 213 packet sequence number. In this case, the OHB has this form: 215 0 1 2 216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 217 +-+-+-+-+-+-+-+-+-------------------------------+ 218 | ID | len=1 | Sequence Number | 219 +-+-+-+-+-+-+-+-+-------------------------------+ 221 If the OHB is three octets in length, it contains the original PT 222 field value and RTP packet sequence number. In this case, the OHB 223 has this form: 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 6 4 5 6 7 8 9 1 227 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 228 | ID | len=2 |R| PT | Sequence Number | 229 +-+-+-+-+-+-+-+-+---------------+-------------------------------+ 231 If a Media Distributor modifies an original RTP header value, the 232 Media Distributor MUST include the OHB extension to reflect the 233 changed value, setting the X bit in the RTP header to 1 if no header 234 extensions were originally present. If another Media Distributor 235 along the media path makes additional changes to the RTP header and 236 any original value is already present in the OHB, the Media 237 Distributor must extend the OHB by adding the changed value to the 238 OHB. To properly preserve original RTP header values, a Media 239 Distributor MUST NOT change a value already present in the OHB 240 extension. 242 5. RTP Operations 244 5.1. Encrypting a Packet 246 To encrypt a packet, the endpoint encrypts the packet using the inner 247 (end-to-end) cryptographic key and then encrypts using the outer 248 (hop-by-hop) cryptographic key. The processes is as follows: 250 o Form an RTP packet. If there are any header extensions, they MUST 251 use [RFC5285]. 253 o If the endpoint wishes to insert header extensions that can be 254 modified by an Media Distributor, it MUST insert an OHB header 255 extension at the end of any header extensions protected end-to-end 256 (if any), then add any Media Distributor-modifiable header 257 extensions. In other cases, the endpoint SHOULD still insert an 258 OHB header extension. The OHB MUST replicate the information 259 found in the RTP header following the application of the inner 260 cryptographic algorithm. If not already set, the endpoint MUST 261 set the X bit in the RTP header to 1 when introducing the OHB 262 extension. 264 o Apply the inner cryptographic algorithm to the RTP packet. If 265 encrypting RTP header extensions end-to-end, then [RFC6904] MUST 266 be used when encrypting the RTP packet using the inner 267 cryptographic key. 269 o Apply the outer cryptographic algorithm to the RTP packet. If 270 encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST 271 be used when encrypting the RTP packet using the outer 272 cryptographic key. 274 When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes 275 after the SRTP packet exactly like using EKT with any other SRTP 276 transform. 278 5.2. Relaying a Packet 280 The Media Distributor does has the part of the key for the outer 281 (hop-by-hop) but does not have the part of the key for the (end-to- 282 end) cryptographic algorithm. The cryptographic algorithm and key 283 used to decrypt a packet and any encrypted RTP header extensions 284 would be the same as those used in the endpoint's outer algorithm and 285 key. 287 In order to modify a packet, the Media Distributor decrypts the 288 packet, modifies the packet, updates the OHB with any modifications 289 not already present in the OHB, and re-encrypts the packet using the 290 cryptographic using the outer (hop-by-hop) key. 292 o Apply the outer (bop-by-hop) cryptographic algorithm to decrypt 293 the packet. If decrypting RTP header extensions hop-by-hop, then 294 [RFC6904] MUST be used. 296 o Change any parts of the RTP packet that the relay wishes to change 297 and are allowed to be changed. 299 o If a changed RTP header field is not already in the OHB, add it 300 with its original value to the OHB. A Media Distributor can add 301 information to the OHB, but MUST NOT change existing information 302 in the OHB. 304 o If the Media Distributor resets a parameter to its original value, 305 it MAY drop it from the OHB as long as there are no other header 306 extensions following the OHB. Note that this might result in a 307 decrease in the size of the OHB. It is also possible for the 308 Media Distributor to remove the OHB entirely if all parameters in 309 the RTP header are reset to their original values and no other 310 header extensions follow the OHB. If the OHB is removed and no 311 other extension is present, the X bit in the RTP header MUST be 312 set to 0. 314 o The Media Distributor MUST NOT delete any header extensions before 315 the OHB, but MAY add, delete, or modify any that follow the OHB. 317 * If the Media Distributor adds any header extensions, it must 318 append them and it must maintain the order of the original 319 header extensions in the [RFC5285] block. 321 * If the Media Distributor appends header extensions, then it 322 MUST add the OHB header extension (if not present), even if the 323 OHB merely replicates the original header field values, and 324 append the new extensions following the OHB. The OHB serves as 325 a demarcation point between original RTP header extensions 326 introduced by the endpoint and those introduced by a Media 327 Distributor. 329 o The Media Distributor MAY modify any header extension appearing 330 after the OHB, but MUST NOT modify header extensions that are 331 present before the OHB. 333 o Apply the outer (hop-by-hop) cryptographic algorithm to the 334 packet. If the RTP Sequence Number has been modified, SRTP 335 processing happens as defined in SRTP and will end up using the 336 new Sequence Number. If encrypting RTP header extensions hop-by- 337 hop, then [RFC6904] MUST be used. 339 5.3. Decrypting a Packet 341 To decrypt a packet, the endpoint first decrypts and verifies using 342 the outer (hop-by-hop) cryptographic key, then uses the OHB to 343 reconstruct the original packet, which it decrypts and verifies with 344 the inner (end-to-end) cryptographic key. 346 o Apply the outer cryptographic algorithm to the packet. If the 347 integrity check does not pass, discard the packet. The result of 348 this is referred to as the outer SRTP packet. If decrypting RTP 349 header extensions hop-by-hop, then [RFC6904] MUST be used when 350 decrypting the RTP packet using the outer cryptographic key. 352 o Form a new synthetic SRTP packet with: 354 * Header = Received header, with header fields replaced with 355 values from OHB (if present). 357 * Insert all header extensions up to the OHB extension, but 358 exclude the OHB and any header extensions that follow the OHB. 359 If there are no extensions remaining, then the X bit MUST bet 360 set to 0. If there are extensions remaining, then the 361 remaining extensions MUST be padded to the first 32-bit 362 boundary and the overall length of the header extensions 363 adjusted accordingly. 365 * Payload is the encrypted payload from the outer SRTP packet. 367 o Apply the inner cryptographic algorithm to this synthetic SRTP 368 packet. Note if the RTP Sequence Number was changed by the Media 369 Distributor, the synthetic packet has the original Sequence 370 Number. If the integrity check does not pass, discard the packet. 371 If decrypting RTP header extensions end-to-end, then [RFC6904] 372 MUST be used when decrypting the RTP packet using the inner 373 cryptographic key. 375 Once the packet has been successfully decrypted, the application 376 needs to be careful about which information it uses to get the 377 correct behaviour. The application MUST use only the information 378 found in the synthetic SRTP packet and MUST NOT use the other data 379 that was in the outer SRTP packet with the following exceptions: 381 o The PT from the outer SRTP packet is used for normal matching to 382 SDP and codec selection. 384 o The sequence number from the outer SRTP packet is used for normal 385 RTP ordering. 387 The PT and sequence number from the inner SRTP packet can be used for 388 collection of various statistics. 390 If any of the following RTP headers extensions are found in the outer 391 SRTP packet, they MAY be used: 393 o Mixer-to-client audio level indicators (See [RFC6465]) 395 6. RTCP Operations 397 Unlike RTP, which is encrypted both hop-by-hop and end-to-end using 398 two separate cryptographic key, RTCP is encrypted using only the 399 outer (hop-by-hop) cryptographic key. The procedures for RTCP 400 encryption are specified in [RFC3711] and this document introduces no 401 additional steps. 403 7. Use with Other RTP Mechanisms 405 There are some RTP related extensions that need special consideration 406 to be used by a relay when using the double transform due to the end- 407 to-end protection of the RTP. 409 7.1. RTX 411 RTX [RFC4588] is not useable by the relay for hop-by-hop repair. 412 Some modification or extension would be need to be made to RTX before 413 it could be used in this way. The problem in using RTX is that the 414 relay would need to be able to read the first two byes of the payload 415 of the retransmissions packet which contain the original sequence 416 number. However, this data is end-to-end encrypted so the relay can 417 not read it. 419 7.2. DTMF 421 When DTMF is sent with [RFC4733], it is end-to-end encrypted and the 422 relay can not read it so it can not be used to controll the relay. 423 Other out of band methods to controll the relay can be used instead. 425 7.3. FEC 427 The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work 428 with no additional considerations. 430 The algorithm recommend in [I-D.ietf-rtcweb-fec] for video is Flex 431 FEC [I-D.ietf-payload-flexible-fec-scheme]. 433 Open Issue: The WG is currently considering how to handle Flex FEC. 434 The main issue of concern is that the FEC Header, which is needed for 435 repair, is part of the RTP payload. Flex FEC and be done before or 436 after the SRTP process with the order controlled by signalling. 437 [I-D.ietf-rtcweb-fec] recommends not using additional FEC only m-line 438 in SDP for the repair packets. 440 8. Recommended Inner and Outer Cryptographic Algorithms 442 This specification recommends and defines AES-GCM as both the inner 443 and outer cryptographic algorithms, identified as 444 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and 445 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. These algorithm provide 446 for authenticated encryption and will consume additional processing 447 time double-encrypting for hop-by-hop and end-to-end. However, the 448 approach is secure and simple, and is thus viewed as an acceptable 449 trade-off in processing efficiency. 451 Note that names for the cryptographic transforms are of the form 452 DOUBLE_(inner algorithm)_(outer algorithm). 454 While this document only defines a profile based on AES-GCM, it is 455 possible for future documents to define further profiles with 456 different inner and outer crypto in this same framework. For 457 example, if a new SRTP transform was defined that encrypts some or 458 all of the RTP header, it would be reasonable for systems to have the 459 option of using that for the outer algorithm. Similarly, if a new 460 transform was defined that provided only integrity, that would also 461 be reasonable to use for the hop-by-hop as the payload data is 462 already encrypted by the end-to-end. 464 The AES-GCM cryptographic algorithm introduces an additional 16 465 octets to the length of the packet. When using AES-GCM for both the 466 inner and outer cryptographic algorithms, the total additional length 467 is 32 octets. If no other header extensions are present in the 468 packet and the OHB is introduced, that will consume an additional 8 469 octets. If other extensions are already present, the OHB will 470 consume up to 4 additional octets. 472 9. Security Considerations 474 To summarize what is encrypted and authenticated, we will refer to 475 all the RTP fields and headers created by the sender and before the 476 pay load as the initial envelope and the RTP payload information with 477 the media as the payload. Any additional headers added by the Media 478 Distributor are referred to as the extra envelope. The sender uses 479 the end-to-end key to encrypts the payload and authenticate the 480 payload + initial envelope which using an AEAD cipher results in a 481 slight longer new payload. Then the sender uses the hop-by-hop key 482 to encrypt the new payload and authenticate the initial envelope and 483 new payload. 485 The Media Distributor has the hop-by-hop key so it can check the 486 authentication of the received packet across the initial envelope and 487 payload data but it can't decrypt the payload as it does not have the 488 end-to-end key. It can add extra envelope information. It then 489 authenticates the initial plus extra envelope information plus 490 payload with a hop-by-hop key. This hop-by-hop for the outgoing 491 packet is typically different than the hop-by-hop key for the 492 incoming packet. 494 The receiver can check the authentication of the initial and extra 495 envelope information. This, along with the OHB, is used to construct 496 a synthetic packet that is should be identical to one the sender 497 created and the receiver can check that it is identical and then 498 decrypt the original payload. 500 The end result is that if the authentications succeed, the receiver 501 knows exactly what the original sender sent, as well as exactly which 502 modifications were made by the Media Distributor. 504 It is obviously critical that the intermediary has only the outer 505 (hop-by-hop) algorithm key and not the half of the key for the the 506 inner (end-to-end) algorithm. We rely on an external key management 507 protocol to assure this property. 509 Modifications by the intermediary result in the recipient getting two 510 values for changed parameters (original and modified). The recipient 511 will have to choose which to use; there is risk in using either that 512 depends on the session setup. 514 The security properties for both the inner (end-to-end) and outer 515 (hop-by-hop) key holders are the same as the security properties of 516 classic SRTP. 518 10. IANA Considerations 520 10.1. RTP Header Extension 522 This document defines a new extension URI in the RTP Compact Header 523 Extensions part of the Real-Time Transport Protocol (RTP) Parameters 524 registry, according to the following data: 526 Extension URI: urn:ietf:params:rtp-hdrext:ohb 528 Description: Original Header Block 529 Contact: Cullen Jennings 531 Reference: RFCXXXX 533 Note to RFC Editor: Replace RFCXXXX with the RFC number of this 534 specification. 536 10.2. DTLS-SRTP 538 We request IANA to add the following values to defines a DTLS-SRTP 539 "SRTP Protection Profile" defined in [RFC5764]. 541 +------------+------------------------------------------+-----------+ 542 | Value | Profile | Reference | 543 +------------+------------------------------------------+-----------+ 544 | {0x00, | DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM | RFCXXXX | 545 | 0x09} | | | 546 | {0x00, | DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM | RFCXXXX | 547 | 0x0A} | | | 548 +------------+------------------------------------------+-----------+ 550 Note to IANA: Please assign value RFCXXXX and update table to point 551 at this RFC for these values. 553 The SRTP transform parameters for each of these protection are: 555 DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM 556 cipher: AES_128_GCM then AES_128_GCM 557 cipher_key_length: 256 bits 558 cipher_salt_length: 192 bits 559 aead_auth_tag_length: 32 octets 560 auth_function: NULL 561 auth_key_length: N/A 562 auth_tag_length: N/A 563 maximum lifetime: at most 2^31 SRTCP packets and 564 at most 2^48 SRTP packets 566 DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM 567 cipher: AES_256_GCM then AES_256_GCM 568 cipher_key_length: 512 bits 569 cipher_salt_length: 192 bits 570 aead_auth_tag_length: 32 octets 571 auth_function: NULL 572 auth_key_length: N/A 573 auth_tag_length: N/A 574 maximum lifetime: at most 2^31 SRTCP packets and 575 at most 2^48 SRTP packets 577 The first half of the key and salt is used for the inner (end-to-end) 578 algorithm and the second half is used for the outer (hop-by-hop) 579 algorithm. 581 11. Acknowledgments 583 Many thanks to Richard Barnes for sending significant text for this 584 specification. Thank you for reviews and improvements from David 585 Benham, Paul Jones, Suhas Nandakumar, Nils Ohlmeier, and Magnus 586 Westerlund. 588 12. References 590 12.1. Normative References 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 598 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 599 RFC 3711, DOI 10.17487/RFC3711, March 2004, 600 . 602 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 603 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 604 2008, . 606 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 607 Security (DTLS) Extension to Establish Keys for the Secure 608 Real-time Transport Protocol (SRTP)", RFC 5764, 609 DOI 10.17487/RFC5764, May 2010, 610 . 612 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 613 Real-time Transport Protocol (SRTP)", RFC 6904, 614 DOI 10.17487/RFC6904, April 2013, 615 . 617 [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption 618 in the Secure Real-time Transport Protocol (SRTP)", 619 RFC 7714, DOI 10.17487/RFC7714, December 2015, 620 . 622 12.2. Informative References 624 [I-D.ietf-payload-flexible-fec-scheme] 625 Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP 626 Payload Format for Flexible Forward Error Correction 627 (FEC)", draft-ietf-payload-flexible-fec-scheme-04 (work in 628 progress), March 2017. 630 [I-D.ietf-perc-dtls-tunnel] 631 Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel 632 between a Media Distributor and Key Distributor to 633 Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-01 634 (work in progress), April 2017. 636 [I-D.ietf-perc-private-media-framework] 637 Jones, P., Benham, D., and C. Groves, "A Solution 638 Framework for Private Media in Privacy Enhanced RTP 639 Conferencing", draft-ietf-perc-private-media-framework-03 640 (work in progress), March 2017. 642 [I-D.ietf-perc-srtp-ekt-diet] 643 Jennings, C., Mattsson, J., McGrew, D., and D. Wing, 644 "Encrypted Key Transport for DTLS and Secure RTP", draft- 645 ietf-perc-srtp-ekt-diet-04 (work in progress), April 2017. 647 [I-D.ietf-rtcweb-fec] 648 Uberti, J., "WebRTC Forward Error Correction 649 Requirements", draft-ietf-rtcweb-fec-05 (work in 650 progress), May 2017. 652 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 653 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 654 DOI 10.17487/RFC4588, July 2006, 655 . 657 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 658 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 659 DOI 10.17487/RFC4733, December 2006, 660 . 662 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 663 time Transport Protocol (RTP) Header Extension for Mixer- 664 to-Client Audio Level Indication", RFC 6465, 665 DOI 10.17487/RFC6465, December 2011, 666 . 668 Authors' Addresses 670 Cullen Jennings 671 Cisco Systems 673 Email: fluffy@iii.ca 675 Paul E. Jones 676 Cisco Systems 678 Email: paulej@packetizer.com 680 Adam Roach 681 Mozilla 683 Email: adam@nostrum.com