idnits 2.17.1 draft-ietf-avtcore-srtp-aes-gcm-15.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 is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2015) is 3293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2675' is mentioned on line 868, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. McGrew 2 Internet Draft Cisco Systems, Inc. 3 Intended Status: Standards Track K. Igoe 4 Expires: October 16, 2015 National Security Agency 5 April 14, 2015 7 AES-GCM Authenticated Encryption in Secure RTP (SRTP) 8 draft-ietf-avtcore-srtp-aes-gcm-15 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF). Note that other groups may also distribute 17 working documents as Internet-Drafts. The list of current Internet- 18 Drafts is at http://datatracker.ietf.org/drafts/current. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 This Internet-Draft will expire on October 16, 2015. 27 Copyright Notice 29 Copyright (c) 2015 IETF Trust and the persons identified as the 30 document authors. All rights reserved. 32 This document is subject to BCP 78 and the IETF Trust's Legal 33 Provisions Relating to IETF Documents 34 (http://trustee.ietf.org/license-info) in effect on the date of 35 publication of this document. Please review these documents 36 carefully, as they describe your rights and restrictions with respect 37 to this document. Code Components extracted from this document must 38 include Simplified BSD License text as described in Section 4.e of 39 the Trust Legal Provisions and are provided without warranty as 40 described in the Simplified BSD License. 42 Abstract 44 This document defines how the AES-GCM Authenticated Encryption with 45 Associated Data family of algorithms can be used to provide 46 confidentiality and data authentication in the SRTP protocol. Note: 47 this is an intermediate draft, awaiting the inclusion of test 48 vectors. Care is being taken to ensure these test vectors will be 49 correct, always a desirable property. 51 Table of Contents 53 1. Introduction.....................................................3 54 2. Conventions Used In This Document................................4 55 3. Overview of the SRTP/SRTCP AEAD security Architecture............4 56 4. Terminology......................................................5 57 5. Generic AEAD Processing..........................................5 58 5.1. Types of Input Data.........................................5 59 5.2. AEAD Invocation Inputs and Outputs..........................5 60 5.2.1. Encrypt Mode...........................................5 61 5.2.2. Decrypt Mode...........................................6 62 5.3. Handling of AEAD Authentication.............................6 63 6. Counter Mode Encryption..........................................6 64 7. Unneeded SRTP/SRTCP Fields.......................................7 65 7.1. SRTP/SRTCP Authentication Field.............................7 66 7.2. RTP Padding.................................................8 67 8. AES-GCM processing for SRTP......................................8 68 8.1. SRTP IV formation for AES-GCM...............................8 69 8.2. Data Types in SRTP Packets..................................8 70 8.3. Handling Header Extensions.................................10 71 8.4. Prevention of SRTP IV Reuse................................11 72 9. AES-GCM Processing of SRTCP Compound Packets....................12 73 9.1. SRTCP IV formation for AES-GCM.............................12 74 9.2. Data Types in Encrypted SRTCP Compound Packets.............13 75 9.3. Data Types in Unencrypted SRTCP Compound Packets...........14 76 9.4. Prevention of SRTCP IV Reuse...............................15 77 10. Constraints on AEAD for SRTP and SRTCP.........................15 78 11. Key Derivation Functions.......................................16 79 12. Summary of AES-GCM in SRTP/SRTCP...............................16 80 13. Security Considerations........................................17 81 13.1. Handling of Security Critical Parameters..................18 82 13.2. Size of the Authentication Tag............................18 83 14. IANA Considerations............................................19 84 14.1. SDES......................................................19 85 14.2. DTLS-SRTP.................................................20 86 14.3. MIKEY.....................................................21 87 15. Parameters for use with MIKEY..................................21 88 16. Acknowledgements...............................................22 89 17. References.....................................................23 90 17.1. Normative References......................................23 91 17.2. Informative References....................................24 93 1. Introduction 95 The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile 96 of the Real-time Transport Protocol (RTP) [RFC3550], which can 97 provide confidentiality, message authentication, and replay 98 protection to the RTP traffic and to the control traffic for RTP, the 99 Real-time Transport Control Protocol (RTCP). It is important to note 100 that the outgoing SRTP packets from a single endpoint may be 101 originating from several independent data sources. 103 Authenticated encryption [BN00] is a form of encryption that, in 104 addition to providing confidentiality for the plaintext that is 105 encrypted, provides a way to check its integrity and authenticity. 106 Authenticated Encryption with Associated Data, or AEAD [R02], adds 107 the ability to check the integrity and authenticity of some 108 Associated Data (AD), also called "additional authenticated data", 109 that is not encrypted. This specification makes use of the interface 110 to a generic AEAD algorithm as defined in [RFC5116]. 112 The Advanced Encryption Standard (AES) is a block cipher that 113 provides a high level of security, and can accept different key 114 sizes. AES Galois/Counter Mode (AES-GCM) [GCM] is a family of AEAD 115 algorithms based upon AES. This specification makes use of the AES 116 versions that use 128-bit and 256-bit keys, which we call AES-128 and 117 AES-256, respectively. 119 Any AEAD algorithm provides an intrinsic authentication tag. In many 120 applications the authentication tag is truncated to less than full 121 length. In this specification the authentication tag MUST be either 122 8 octets or 16 octets in length, and the 8 byte authentication tag 123 can only be used with AES-128. Thus when used in SRTP, GCM will have 124 three configurations: 126 AEAD_AES_128_GCM_8 AES-128 with an 8 byte authentication tag 127 AEAD_AES_128_GCM AES-128 with a 16 byte authentication tag 128 AEAD_AES_256_GCM AES-256 with a 16 byte authentication tag 130 The key size and the length of the authentication tag are set when 131 the session is initiated and SHOULD NOT be altered. 133 The Galois/Counter Mode of operation (GCM) ia an AEAD mode of 134 operation for block ciphers. GCM use counter mode to encrypt the 135 data, an operation that can be efficiently pipelined. Further, GCM 136 authentication uses operations that are particularly well suited to 137 efficient implementation in hardware, making it especially appealing 138 for high-speed implementations, or for implementations in an 139 efficient and compact circuit. 141 In summary, this document defines how to use an AEAD algorithm, 142 particularly AES-GCM, to provide confidentiality and message 143 authentication within SRTP and SRTCP packets. 145 2. Conventions Used In This Document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 [RFC2119]. 152 3. Overview of the SRTP/SRTCP AEAD security Architecture 154 SRTP/SRTCP AEAD security is based upon the following principles: 156 a) Both privacy and authentication are based upon the use of 157 symmetric algorithms. An AEAD algorithm such as AES-GCM 158 combines privacy and authentication into a single process. 160 b) A secret master key is shared by all participating endpoints, 161 both those originating SRTP/SRTCP packets and those receiving 162 these packets. Any given master key MAY be used 163 simultaneously by several endpoints to originate SRTP/SRTCP 164 packets (as well one or more endpoints using this master key 165 to process inbound data). 167 c) A Key Derivation Function is applied to the shared master key 168 value to form separate encryption keys, authentication keys 169 and salting keys for SRTP and for SRTCP (a total of six 170 keys). This process is described in section 4.3 of 171 [RFC3711]. The master key MUST be at least as large as the 172 encryption key derived from it. Since AEAD algorithms such 173 as AES-GCM combine encryption and authentication into a 174 single process, AEAD algorithms do not make use of separate 175 authentication keys. 177 d) Aside from making modifications to IANA registries to allow 178 AES-GCM to work with SDES, DTLS-SRTP and MIKEY, the details 179 of how the master key is established and shared between the 180 participants are outside the scope of this document. 181 Similarly any mechanism for rekeying an existing session is 182 outside the scope of the document. 184 e) Each time an instantiation of AES-GCM is invoked to encrypt 185 and authenticate an SRTP or SRTCP data packet a new IV is 186 used. SRTP combines the 4-octet synchronization source 187 (SSRC) identifier, the 4-octet rollover counter (ROC), and 188 the 2-octet sequence number (SEQ) with the 12-octet 189 encryption salt to form a 12-octet IV (see section 8.1). 190 SRTCP combines the SSRC and 31-bit SRTCP index with the 191 encryption salt to form a 12-octet IV (see section 9.1). 193 4. Terminology 195 The following terms have very specific meanings in the context of 196 this RFC: 198 Instantiation: In AEAD, an instantiation is an (Encryption_key, 199 salt) pair together with all of the data 200 structures (for example, counters) needed for it 201 to function properly. In SRTP/SRTCP, each 202 endpoint will need two instantiations of the AEAD 203 algorithm for each master key in its possession, 204 one instantiation for SRTP traffic and one 205 instantiation for SRTCP traffic. 207 Invocation: SRTP/SRTCP data streams are broken into packets. 208 Each packet is processed by a single invocation 209 of the appropriate instantiation of the AEAD 210 algorithm. 212 In many applications, each endpoint will have one master key for 213 processing outbound data but may have one or more separate master 214 keys for processing inbound data. 216 5. Generic AEAD Processing 218 5.1. Types of Input Data 220 Associated Data: This is data that is to be authenticated 221 but not encrypted. 223 Plaintext: Data that is to be both encrypted and 224 authenticated. 226 Raw Data: Data that is to be neither encrypted nor 227 authenticated. 229 Which portions of SRTP/SRTCP packets that are to be treated as 230 associated data, which are to be treated as plaintext, and which are 231 to be treated as raw data are covered in sections 8.2, 9.2 and 9.3. 233 5.2. AEAD Invocation Inputs and Outputs 235 5.2.1. Encrypt Mode 237 Inputs: 238 Encryption_key Octet string, either 16 or 32 239 octets long 241 Initialization_Vector Octet string, 12 octets long 242 Associated_Data Octet string of variable length 243 Plaintext Octet string of variable length 245 Outputs 246 Ciphertext* Octet string, length = 247 length(Plaintext)+tag_length 249 (*): In AEAD the authentication tag in embedded in the cipher text. 250 When GCM is being used the ciphertext consists of the encrypted plain 251 text followed by the authentication tag. 253 5.2.2. Decrypt Mode 255 Inputs: 256 Encryption_key Octet string, either 16 or 32 257 octets long 258 Initialization_Vector Octet string, 12 octets long 259 Associated_Data Octet string of variable length 260 Ciphertext Octet string of variable length 262 Outputs 263 Plaintext Octet string, length = 264 length(Ciphertext)-tag_length 265 Validity_Flag Boolean, TRUE if valid, 266 FALSE otherwise 268 5.3. Handling of AEAD Authentication 270 AEAD requires that all incoming packets MUST pass AEAD authentication 271 before any other action takes place. Plaintext and associated data 272 MUST NOT be released until the AEAD authentication tag has been 273 validated. Further the ciphertext MUST NOT be decrypted until the 274 AEAD tag has been validated. 276 Should the AEAD tag prove to be invalid, the packet in question is to 277 be discarded and a Validation Error flag raised. Local policy 278 determines how this flag is to be handled and is outside the scope of 279 this document. 281 6. Counter Mode Encryption 283 Each outbound packet uses a 12-octet IV and an encryption key to form 284 two outputs, a 16-octet first_key_block which is used in forming the 285 authentication tag and a key stream of octets, formed in blocks of 286 16-octets each. The first 16-octet block of key is saved for use in 287 forming the authentication tag, and the of remainder of the key 288 stream is XORed to the plaintext to form cipher. This key stream is 289 formed one block at a time by inputting the concatenation of a 290 12-octet IV (see sections 8.1 and 9.1) with a 4-octet block to AES. 291 The pseudo-code below illustrates this process: 293 def GCM_keystream( Plaintext_len, IV, Encryption_key ): 294 assert Plaintext_len <= (2**36) - 32 ## measured in octets 295 key_stream = "" 296 block_counter = 1 297 first_key_block = AES_ENC( data=IV||block_counter, 298 key=Encryption_key ) 299 while len(key_stream) < Plaintext_len: 300 block_counter = block_counter + 1 301 key_block = AES_ENC( data=IV||block_counter, 302 key=Encryption_key ) 303 key_stream = key_stream || key_block 304 key_stream = truncate( key_stream, Plaintext_len ) 305 return (first_key_block, key_stream ) 307 In theory this keystream generation process allows for the encryption 308 of up to (2^36)-32 octets per invocation (i.e. per packet), far 309 longer than is actually required. 311 With any counter mode, if the same (IV, Encryption_key) pair is used 312 twice, precisely the same keystream is formed. As explained in 313 section 9.1 of RFC 3711, this is a cryptographic disaster. For GCM 314 the consequences are even worse since such a reuse compromises GCM's 315 integrity mechanism not only for the current packet stream but for 316 all future uses of the current encryption_key. 318 7. Unneeded SRTP/SRTCP Fields 320 AEAD counter mode encryption removes the need for certain existing 321 SRTP/SRTCP mechanisms. 323 7.1. SRTP/SRTCP Authentication Field 325 The AEAD message authentication mechanism MUST be the primary message 326 authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP 327 authentication mechanisms SHOULD NOT be used with any AEAD algorithm 328 and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED 329 and SHOULD NOT be present. Note that this contradicts section 3.4 of 330 [RFC3711] which makes the use of the SRTCP Authentication field 331 mandatory, but the presence of the AEAD authentication renders the 332 older authentication methods redundant. 334 Rationale. Some applications use the SRTP/SRTCP Authentication 335 Tag as a means of conveying additional information, notably 336 [RFC4771]. This document retains the Authentication Tag field 337 primarily to preserve compatibility with these applications. 339 7.2. RTP Padding 341 AES-GCM does not requires that the data be padded out to a specific 342 block size, reducing the need to use the padding mechanism provided 343 by RTP. It is RECOMMENDED that the RTP padding mechanism not be used 344 unless it is necessary to disguise the length of the underlying 345 plaintext. 347 8. AES-GCM processing for SRTP 349 8.1. SRTP IV formation for AES-GCM 351 0 0 0 0 0 0 0 0 0 0 1 1 352 0 1 2 3 4 5 6 7 8 9 0 1 353 +--+--+--+--+--+--+--+--+--+--+--+--+ 354 |00|00| SSRC | ROC | SEQ |---+ 355 +--+--+--+--+--+--+--+--+--+--+--+--+ | 356 | 357 +--+--+--+--+--+--+--+--+--+--+--+--+ | 358 | Encryption Salt |->(+) 359 +--+--+--+--+--+--+--+--+--+--+--+--+ | 360 | 361 +--+--+--+--+--+--+--+--+--+--+--+--+ | 362 | Initialization Vector |<--+ 363 +--+--+--+--+--+--+--+--+--+--+--+--+ 365 Figure 1: AES-GCM SRTP Initialization 366 Vector formation. 367 The 12 octet initialization vector used by AES-GCM SRTP is formed by 368 first concatenating 2-octets of zeroes, the 4-octet SSRC, the 4-octet 369 Rollover Counter (ROC) and the two octet sequence number SEQ. The 370 resulting 12-octet value is then XORed to the 12-octet salt to form 371 the 12-octet IV. 373 8.2. Data Types in SRTP Packets 375 All SRTP packets MUST be both authenticated and encrypted. The data 376 fields within the SRTP packets are broken into Associated Data, 377 Plaintext and Raw Data as follows (see Figure 2): 379 Associated Data: The version V (2 bits), padding flag P (1 bit), 380 extension flag X (1 bit), CSRC count CC (4 bits), 381 marker M (1 bit), the Payload Type PT (7 bits), 382 the sequence number (16 bits), timestamp (32 383 bits), SSRC (32 bits), optional contributing 384 source identifiers (CSRCs, 32 bits each), and 385 optional RTP extension (variable length). 387 Plaintext: The RTP payload (variable length), RTP padding 388 (if used, variable length), and RTP pad count ( 389 if used, 1 octet). 391 Raw Data: The optional variable length SRTP MKI and SRTP 392 authentication tag (whose use is NOT 393 RECOMMENDED). These fields are appended after 394 encryption has been performed. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 A |V=2|P|X| CC |M| PT | sequence number | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 A | timestamp | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 A | synchronization source (SSRC) identifier | 404 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 405 A | contributing source (CSRC) identifiers (optional) | 406 A | .... | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 A | RTP extension (OPTIONAL) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 P | payload ... | 411 P | +-------------------------------+ 412 P | | RTP padding | RTP pad count | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 P = Plaintext (to be encrypted and authenticated) 416 A = Associated Data (to be authenticated only) 418 Figure 2: Structure of an SRTP packet before Authenticated 419 Encryption 421 Since the AEAD ciphertext is larger than the plaintext by exactly the 422 length of the AEAD authentication tag, the corresponding SRTP 423 encrypted packet replaces the plaintext field by a slightly larger 424 field containing the cipher. Even if the plaintext field is empty, 425 AEAD encryption must still be performed, with the resulting cipher 426 consisting solely of the authentication tag. This tag is to be 427 placed immediately before the optional variable length SRTP MKI and 428 SRTP authentication tag fields. 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 A |V=2|P|X| CC |M| PT | sequence number | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 A | timestamp | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 A | synchronization source (SSRC) identifier | 438 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 439 A | contributing source (CSRC) identifiers (optional) | 440 A | .... | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 A | RTP extension (OPTIONAL) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 C | cipher | 445 C | ... | 446 C | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 R : SRTP MKI (OPTIONAL) : 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 R : SRTP authentication tag (NOT RECOMMENDED) : 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 C = Ciphertext (encrypted and authenticated) 454 A = Associated Data (authenticated only) 455 R = neither encrypted nor authenticated, added 456 after authenticated encryption completed 458 Figure 3: Structure of an SRTP packet after Authenticated 459 Encryption 461 8.3. Handling Header Extensions 463 RTP header extensions were first defined in RFC 3550. RFC 6904 464 [RFC6904] describes how these header extensions are to be encrypted 465 in SRTP. 467 When RFC 6904 is in use, a separate keystream is generated to encrypt 468 selected RTP header extension elements. For the AEAD_AES_128_GCM and 469 AEAD_AES_128_GCM_8 algorithms, this keystream MUST be generated in 470 the manner defined in [RFC6904] using the AES_128_CM transform. For 471 the AEAD_AES_256_GCM algorithm, the keystream MUST be generated in 472 the manner defined for the AES_256_CM transform. The originator must 473 perform any required header extension encryption before the AEAD 474 algorithm is invoked. 476 As with the other fields contained within the RTP header, both 477 encrypted and unencrypted header extensions are to be treated by the 478 AEAD algorithm as Associated Data (AD). Thus the AEAD algorithm does 479 not provide any additional privacy for the header extensions, but 480 does provide integrity and authentication. 482 8.4. Prevention of SRTP IV Reuse 484 In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC) 485 triple is never used twice with the same master key. There are two 486 phases to this issue. 488 Counter Management: A rekey MUST be performed to establish a new 489 master key before the (ROC,SEQ) pair cycles 490 back to its original value. Note that 491 implicitly assumes that either the outgoing RTP 492 process is trusted to not attempt to repeat a 493 (ROC,SEQ) value, or that the encryption process 494 ensures that the both the SEQ and ROC numbers 495 of the packets presented to it are always 496 incremented in the proper fashion. This is 497 particularly important for GCM since using the 498 same (ROC,SEQ) value twice compromises the 499 authentication mechanism. For GCM, the 500 (ROC,SEQ) and SSRC values used MUST either be 501 generated or checked by the SRTP 502 implementation, or by a module (e.g. the RTP 503 application) that can be considered equally 504 trusted as the SRTP implementation. While 505 [RFC3711] allows detecting SSRC collisions 506 after they happen, SRTP using GCM with shared 507 master keys MUST prevent SSRC collision from 508 happening even once. 510 SSRC Management: For a given master key, the set of all SSRC 511 values used with that master key must be 512 partitioned into disjoint pools, one pool for 513 each endpoint using that master key to 514 originate outbound data. Each such originating 515 endpoint MUST only issue SSRC values from the 516 pool it has been assigned. Further, each 517 originating endpoint MUST maintain a history of 518 outbound SSRC identifiers that it has issued 519 within the lifetime of the current master key, 520 and when a new synchronization source requests 521 an SSRC identifier it MUST NOT be given an 522 identifier that has been previously issued. A 523 rekey MUST be performed before any of the 524 originating endpoints using that master key 525 exhausts its pool of SSRC values. Further, the 526 identity of the entity giving out SSRC values 527 MUST be verified, and the SSRC signaling MUST 528 be integrity protected. 530 9. AES-GCM Processing of SRTCP Compound Packets 532 All SRTCP compound packets MUST be authenticated, but unlike SRTP, 533 SRTCP packet encryption is optional. A sender can select which 534 packets to encrypt, and indicates this choice with a 1-bit encryption 535 flag (located just before the 31-bit SRTCP index) 537 9.1. SRTCP IV formation for AES-GCM 539 The 12-octet initialization vector used by AES-GCM SRTCP is formed by 540 first concatenating 2-octets of zeroes, the 4-octet Synchronization 541 Source identifier (SSRC), 2-octets of zeroes, a single zero bit, and 542 the 31-bit SRTCP Index. The resulting 12-octet value is then XORed 543 to the 12-octet salt to form the 12-octet IV. 545 0 1 2 3 4 5 6 7 8 9 9 11 546 +--+--+--+--+--+--+--+--+--+--+--+--+ 547 |00|00| SSRC |00|00|0+SRTCP Idx|---+ 548 +--+--+--+--+--+--+--+--+--+--+--+--+ | 549 | 550 +--+--+--+--+--+--+--+--+--+--+--+--+ | 551 | Encryption Salt |->(+) 552 +--+--+--+--+--+--+--+--+--+--+--+--+ | 553 | 554 +--+--+--+--+--+--+--+--+--+--+--+--+ | 555 | Initialization Vector |<--+ 556 +--+--+--+--+--+--+--+--+--+--+--+--+ 558 Figure 4: SRTCP Initialization Vector formation 560 9.2. Data Types in Encrypted SRTCP Compound Packets 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 A |V=2|P| RC | Packet Type | length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 A | synchronization source (SSRC) of Sender | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 P | sender info : 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 P | report block 1 : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 P | report block 2 : 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 P | ... : 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 P |V=2|P| SC | Packet Type | length | 578 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 579 P | SSRC/CSRC_1 | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 P | SDES items : 582 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 583 P | ... : 584 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 585 A |1| SRTCP index | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 R | SRTCP MKI (optional) index : 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 R : SRTCP authentication tag (NOT RECOMMENDED) : 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 P = Plaintext (to be encrypted and authenticated) 593 A = Associated Data (to be authenticated only) 594 R = neither encrypted nor authenticated, added after 595 encryption 597 Figure 5: AEAD SRTCP inputs when encryption flag = 1. 599 When the encryption flag is set to 1, the SRTCP packet is broken into 600 plaintext, associated data, and raw (untouched) data (as shown above 601 in figure 5): 603 Associated Data: The packet version V (2 bits), padding flag P (1 604 bit), reception report count RC (5 bits), packet 605 type (8 bits), length (2 octets), SSRC (4 606 octets), encryption flag (1 bit) and SRTCP index 607 (31 bits). 609 Raw Data: The optional variable length SRTCP MKI and SRTCP 610 authentication tag (whose use is NOT 611 RECOMMENDED). 613 Plaintext: All other data. 615 Note that the plaintext comes in one contiguous field. Since the 616 AEAD cipher is larger than the plaintext by exactly the length of the 617 AEAD authentication tag, the corresponding SRTCP encrypted packet 618 replaces the plaintext field with a slightly larger field containing 619 the cipher. Even if the plaintext field is empty, AEAD encryption 620 must still be performed, with the resulting cipher consisting solely 621 of the authentication tag. This tag is to be placed immediately 622 before the encryption flag and SRTCP index. 624 9.3. Data Types in Unencrypted SRTCP Compound Packets 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 A |V=2|P| RC | Packet Type | length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 A | synchronization source (SSRC) of Sender | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 A | sender info : 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 A | report block 1 : 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 A | report block 2 : 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 A | ... : 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 A |V=2|P| SC | Packet Type | length | 642 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 643 A | SSRC/CSRC_1 | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 A | SDES items : 646 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 647 A | ... : 648 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 649 A |0| SRTCP index | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 R | SRTCP MKI (optional) index : 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 R : authentication tag (NOT RECOMMENDED) : 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 A = Associated Data (to be authenticated only) 657 R = neither encrypted nor authenticated, added after 658 encryption 660 Figure 6: AEAD SRTCP inputs when encryption flag = 0 662 When the encryption flag is set to 0, the SRTCP compound packet is 663 broken into plaintext, associated data, and raw (untouched) data as 664 follows (see figure 6): 666 Plaintext: None. 668 Raw Data: The variable length optional SRTCP MKI and SRTCP 669 authentication tag (whose use is NOT 670 RECOMMENDED). 672 Associated Data: All other data. 674 Even though there is no ciphertext in this RTCP packet, AEAD 675 encryption returns a cipher field which is precisely the length of 676 the AEAD authentication tag. This cipher is to be placed before the 677 Encryption flag and the SRTCP index in the authenticated SRTCP 678 packet. 680 9.4. Prevention of SRTCP IV Reuse 682 A new master key MUST be established before the 31-bit SRTCP index 683 cycles back to its original value. Ideally, a rekey should be 684 performed and a new master key put in place well before the SRTCP 685 cycles back to the starting value. 687 The comments on SSRC management in section 8.4 also apply. 689 10. Constraints on AEAD for SRTP and SRTCP 691 In general, any AEAD algorithm can accept inputs with varying 692 lengths, but each algorithm can accept only a limited range of 693 lengths for a specific parameter. In this section, we describe the 694 constraints on the parameter lengths that any AEAD algorithm must 695 support to be used in AEAD-SRTP. Additionally, we specify a complete 696 parameter set for one specific fasmily of AEAD algorithms, namely 697 AES-GCM. 699 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the five 700 constraints listed below: 702 PARAMETER Meaning Value 704 A_MAX maximum associated MUST be at least 12 octets. 705 data length 706 N_MIN minimum nonce (IV) MUST be 12 octets. 707 length 708 N_MAX maximum nonce (IV) MUST be 12 octets. 709 length 710 P_MAX maximum plaintext GCM: MUST be <= 2^36-32 octets. 711 length per invocation 713 C_MAX maximum ciphertext GCM: MUST be <= 2^36-16 octets. 714 length per invocation 716 For sake of clarity we specify two additional parameters: 718 AEAD Authentication Tag Length MUST be 8 or 16 octets, 719 Maximum number of invocations SRTP: MUST be at most 2^48, 720 for a given instantiation SRTCP: MUST be at most 2^31. 721 Block Counter size GCM: MUST be 32 bits. 723 The reader is reminded that the ciphertext is longer than the 724 plaintext by exactly the length of the AEAD authentication tag. 726 11. Key Derivation Functions 728 A Key Derivation Function (KDF) is used to derive all of the required 729 encryption and authentication keys from a secret value shared by the 730 endpoints. Both AEAD_AES_128_GCM and AEAD_AES_128_GCM_8 algorithms 731 MUST use the (128-bit) AES_CM_PRF Key Derivation Function described 732 in [RFC3711]. AEAD_AES_256_GCM MUST use the AES_256_CM_PRF Key 733 Derivation Function described in [RFC6188]. 735 12. Summary of AES-GCM in SRTP/SRTCP 737 For convenience, much of the information about the use of AES-GCM 738 family of algorithms in SRTP is collected in the tables contained in 739 this section. 741 The AES-GCM family of AEAD algorithms built around the AES block 742 cipher algorithm. AES-GCM uses AES counter mode for encryption and 743 Galois Message Authentication Code (GMAC) for authentication. A 744 detailed description of the AES-GCM family can be found in 745 [RFC5116]. The following members of the AES-GCM family may be used 746 with SRTP/SRTCP: 748 Name Key Size AEAD Tag Size Reference 749 ================================================================ 750 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 751 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 752 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 754 Table 1: AES-GCM algorithms for SRTP/SRTCP 756 Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM 757 and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication 758 tags), and it MAY support AEAD_AES_128_GCM_8. Below we summarize 759 parameters associated with these three GCM algorithms: 761 +--------------------------------+------------------------------+ 762 | Parameter | Value | 763 +--------------------------------+------------------------------+ 764 | Master key length | 128 bits | 765 | Master salt length | 96 bits | 766 | Key Derivation Function | AES_CM_PRF [RFC3711] | 767 | Maximum key lifetime (SRTP) | 2^48 packets | 768 | Maximum key lifetime (SRTCP) | 2^31 packets | 769 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_GCM_8 | 770 | AEAD authentication tag length | 64 bits | 771 +--------------------------------+------------------------------+ 773 Table 2: The AEAD_AES_128_GCM_8 Crypto Suite 775 +--------------------------------+------------------------------+ 776 | Parameter | Value | 777 +--------------------------------+------------------------------+ 778 | Master key length | 128 bits | 779 | Master salt length | 96 bits | 780 | Key Derivation Function | AES_CM_PRF [RFC3711] | 781 | Maximum key lifetime (SRTP) | 2^48 packets | 782 | Maximum key lifetime (SRTCP) | 2^31 packets | 783 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_GCM | 784 | AEAD authentication tag length | 128 bits | 785 +--------------------------------+------------------------------+ 787 Table 3: The AEAD_AES_128_GCM Crypto Suite 789 +--------------------------------+------------------------------+ 790 | Parameter | Value | 791 +--------------------------------+------------------------------+ 792 | Master key length | 256 bits | 793 | Master salt length | 96 bits | 794 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 795 | Maximum key lifetime (SRTP) | 2^48 packets | 796 | Maximum key lifetime (SRTCP) | 2^31 packets | 797 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_GCM | 798 | AEAD authentication tag length | 128 bits | 799 +--------------------------------+------------------------------+ 800 Table 4: The AEAD_AES_256_GCM Crypto Suite 802 13. Security Considerations 803 13.1. Handling of Security Critical Parameters 805 As with any security process, the implementer must take care to 806 ensure cryptographically sensitive parameters are properly handled. 807 Many of these recommendations hold for all SRTP cryptographic 808 algorithms, but we include them here to emphasize their importance. 810 - If the master salt is to be kept secret, it MUST be properly 811 erased when no longer needed. 812 - The secret master key and all keys derived from it MUST be kept 813 secret. All keys MUST be properly erased when no longer 814 needed. 815 - At the start of each packet, the block counter MUST be reset to 816 1. The block counter is incremented after each block key has 817 been produced, but it MUST NOT be allowed to exceed 2^32-1 for 818 GCM. Note that even though the block counter is reset at the 819 start of each packet, IV uniqueness is ensured by the inclusion 820 of SSRC/ROC/SEQ or SRTCP Index in the IV. (The reader is 821 reminded that the first block of key produced is reserved for 822 use in authenticating the packet and is not used to encrypt 823 plaintext.) 824 - Each time a rekey occurs, the initial values of both the 31-bit 825 SRTCP index and the 48-bit SRTP packet index (ROC||SEQ) MUST be 826 saved in order to prevent IV reuse. 827 - Processing MUST cease if either the 31-bit SRTCP index or the 828 48-bit packet index ROC||SEQ cycles back their initial values . 829 Processing MUST NOT resume until a new SRTP/SRTCP session has 830 been established using a new SRTP master key. Ideally, a rekey 831 should be done well before any of these counters cycle. 833 13.2. Size of the Authentication Tag 835 We require that the AEAD authentication tag must be at least 8 836 octets, significantly reducing the probability of an adversary 837 successfully introducing fraudulent data. The goal of an 838 authentication tag is to reduce the probability of a successful 839 forgery occurring anywhere in the network we are attempting to 840 defend. There are three relevant factors: how low we wish the 841 probability of successful forgery to be (prob_success), how many 842 attempts the adversary can make (N_tries) and the size of the 843 authentication tag in bits (N_tag_bits). Then 845 prob_success <= expected number of successes 846 = N_tries * 2^-N_tag_bits. 848 When the expected number of successes is much less than one, the 849 probability of success is well approximated by the expected number of 850 successes. 852 Suppose an adversary wishes to introduce a forged or altered packet 853 into a target network by randomly selecting an authentication value 854 until by chance they hit a valid authentication tag. The table below 855 summarizes the relationship between the number of forged packets the 856 adversary has tried, the size of the authentication tag, and the 857 probability of a compromise occurring (i.e. at least one of the 858 attempted forgeries having a valid authentication tag). The reader 859 is reminded that the forgery attempts can be made over the entire 860 network, not just a single link, and that frequently changing the key 861 does not decrease the probability of a compromise occurring. 863 It should be noted that the cryptographic properties of the GHASH 864 algorithm used in GCM reduces the effective authentication tag size 865 (in bits) by the log base 2 of the of blocks of encrypted and/or 866 authenticated data in a packet. In practice an SRTP payload will be 867 less than 2^16 bytes, because of the 16-bit IPv4 and UDP length 868 fields. The exception to this case is IPv6 jumbograms [RFC2675], 869 which is unlikely to be used for RTP-based multimedia traffic 870 [RFC3711]. This corresponds to 2^12 blocks of data, so the effective 871 GCM authentication tag size is reduced by at most 12 bits. 873 +===========+=============+========================================+ 874 | Auth. Tag | Effective | Number of Forgery Attempts | 875 | Size | Tag Size | Needed to Achieve a Given | 876 | (bytes) | (bits) | Probability of Success | 877 |-----------+-------------+------------+-------------+-------------| 878 | | prob=2^-30 | prob=2^-20 | prob=2^-10 | 879 |===========+=============+=============+============+=============| 880 | 4 | 20 (GCM) | 1 try | 1 try | 2^10 tries | 881 |===========+=============+============+=============+=============| 882 | 8 | 52 (GCM) | 2^22 tries | 2^32 tries | 2^42 tries | 883 |===========+=============+============+=============+=============| 884 | 12 | 84 (GCM) | 2^54 tries | 2^64 tries | 2^74 tries | 885 |===========+=============+============+=============+=============| 886 | 16 | 116 (GCM) | 2^86 tries | 2^96 tries | 2^106 tries | 887 |===========+=============+============+=============+=============| 889 Table 5: Number of forgery attempts needed to achieve a given 890 probability of success for various tag sizes. 892 14. IANA Considerations 894 14.1. SDES 896 SDP Security Descriptions [RFC4568] defines SRTP "crypto suites". A 897 crypto suite corresponds to a particular AEAD algorithm in SRTP. In 898 order to allow Security Descriptions to signal the use of the 899 algorithms defined in this document, IANA will register the following 900 crypto suites into the "SRTP Crypto Suite Registrations" subregistry 901 of the "Session Description Protocol (SDP) Security Descriptions" 902 registry. 904 srtp-crypto-suite-ext = "AEAD_AES_128_GCM_8" / 905 "AEAD_AES_128_GCM" / 906 "AEAD_AES_256_GCM" / 907 srtp-crypto-suite-ext 909 14.2. DTLS-SRTP 911 DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile". 912 These also correspond to the use of an AEAD algorithm in SRTP. In 913 order to allow the use of the algorithms defined in this document in 914 DTLS-SRTP, we request IANA register the following SRTP Protection 915 Profiles: 917 AEAD_AES_128_GCM = {TBD, TBD } 918 AEAD_AES_128_GCM_8 = {TBD, TBD } 919 AEAD_AES_256_GCM = {TBD, TBD } 921 Below we list the SRTP transform parameters for each of these 922 protection profile. Unless separate parameters for SRTCP and SRTCP 923 are explicitly listed, these parameters apply to both SRTP and 924 SRTCP. 926 AEAD_AES_128_GCM 927 cipher: AES_128_GCM 928 cipher_key_length: 128 bits 929 cipher_salt_length: 96 bits 930 aead_auth_tag_length: 16 octets 931 auth_function: NULL 932 auth_key_length: N/A 933 auth_tag_length: N/A 934 maximum lifetime: at most 2^31 SRTCP packets and 935 at most 2^48 SRTP packets 936 AEAD_AES_128_GCM_8 937 cipher: AES_128_GCM 938 cipher_key_length: 128 bits 939 cipher_salt_length: 96 bits 940 aead_auth_tag_length: 8 octets 941 auth_function: NULL 942 auth_key_length: N/A 943 auth_tag_length: N/A 944 maximum lifetime: at most 2^31 SRTCP packets and 945 at most 2^48 SRTP packets 947 AEAD_AES_256_GCM 948 cipher: AES_256_GCM 949 cipher_key_length: 256 bits 950 cipher_salt_length: 96 bits 951 aead_auth_tag_length: 16 octets 952 auth_function: NULL 953 auth_key_length: N/A 954 auth_tag_length: N/A 955 maximum lifetime: at most 2^31 SRTCP packets and 956 at most 2^48 SRTP packets 958 Note that these SRTP Protection Profiles do not specify an 959 auth_function, auth_key_length, or auth_tag_length because all of 960 these profiles use AEAD algorithms, and thus do not use a separate 961 auth_function, auth_key, or auth_tag. The term aead_auth_tag_length 962 is used to emphasize that this refers to the authentication tag 963 provided by the AEAD algorithm and that this tag is not located in 964 the authentication tag field provided by SRTP/SRTCP. 966 14.3. MIKEY 968 In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], 969 IANA maintains several subregitries under "Multimedia Internet KEYing 970 (MIKEY) Payload Name Spaces". This document requires additions to 971 two of the MIKEY subregistries. 973 In the "MIKEY Security Protocol Parameters" subregistry we request 974 the following addition: 976 Type | Meaning | Possible values 977 ---------------------------------------------------------------- 978 TBD | AEAD authentication tag length | 8 octets or 16 octets 980 This list is, of course, intended for use with GCM. It is 981 conceivable that new AEAD algorithms introduced at some point in the 982 future may require a different set of Authentication tag lengths. 984 In the "Encryption Algorithm" subregistry (derived from Table 985 6.10.1.b of [RFC3830]) we request the following addition: 987 SRTP encr | Value | Default Session | Default Auth. 988 Algorithm | | Encr. Key Length | Tag Length 989 ----------------------------------------------------------- 990 AES-GCM | TBD | 16 octets | 16 octets 992 The SRTP encryption algorithm, session encryption key length, and 993 AEAD authentication tag values received from MIKEY fully determine 994 the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is 995 described in section 16. 997 15. Parameters for use with MIKEY 998 MIKEY specifies the algorithm family separately from the key length 999 (which is specified by the Session Encryption key length) and the 1000 authentication tag length (specified by AEAD Auth. tag length). 1002 +------------+-------------+-------------+ 1003 | Encryption | Encryption | AEAD Auth. | 1004 | Algorithm | Key Length | Tag Length | 1005 +============+=============+=============+ 1006 AEAD_AES_128_GCM_8 | AES-GCM | 16 octets | 8 octets | 1007 +------------+-------------+-------------+ 1008 AEAD_AES_128_GCM | AES-GCM | 16 octets | 16 octets | 1009 +------------+-------------+-------------+ 1010 AEAD_AES_256_GCM | AES-GCM | 32 octets | 16 octets | 1011 +============+=============+=============+ 1013 Table 6: Mapping MIKEY parameters to AEAD algorithm 1015 Section 11 in this document restricts the choice of Key Derivation 1016 Function for AEAD algorithms. To enforce this restriction in MIKEY, 1017 we require that the SRTP PRF has value AES-CM whenever an AEAD 1018 algorithm is used. Note that, according to Section 6.10.1 in 1019 [RFC3830], the input key length of the Key Derivation Function (i.e. 1020 the SRTP master key length) is always equal to the session encryption 1021 key length. This means, for example, that AEAD_AES_256_GCM will use 1022 AES_256_CM_PRF as the Key Derivation Function. 1024 16. Acknowledgements 1026 The authors would like to thank Michael Peck, Michael Torla, Qin Wu, 1027 Magnus Westerland, Oscar Ohllson, Woo-Hwan Kim, John Mattsson, 1028 Richard Barnes, John Mattisson, Morris Dworkin, Stehen Farrell and 1029 many other reviewers who provided valuable comments on earlier drafts 1030 of this document. 1032 17. References 1034 17.1. Normative References 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", BCP 14, RFC 2119, March 1997. 1039 [RFC3550] Casner, S., Frederick, R., and V. Jacobson, "RTP: A 1040 Transport Protocol for Real-Time Applications", RFC 3550, 1041 July 2003. 1043 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 1044 K. Norrman, "The Secure Real-time Transport Protocol 1045 (SRTP)", RFC 3711, September 2003. 1047 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and 1048 Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1049 August 2004. 1051 [RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session 1052 Description Protocol (SDP): Security Descriptions for 1053 Media Streams", RFC 4568, July 2006. 1055 [RFC5116] McGrew, D., "An Interface and Algorithms for 1056 Authenticated Encryption with Associated Data", RFC 5116, 1057 January 2008. 1059 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 1060 Algorithms with the Encrypted Payload of the Internet Key 1061 Exchange version 2 (IKEv2) Protocol", RFC 5282, 1062 August 2008. 1064 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1065 Security (DTLS) Extension to Establish Keys for the Secure 1066 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1068 [RFC6188] D. McGrew, "The Use of AES-192 and AES-256 in Secure 1069 RTP", RFC 6188, March 2011. 1071 [RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure 1072 Real-Time Transport Protocol (SRTP)", January 2013. 1074 , January 2013. 1076 [RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure 1077 Real-Time Transport Protocol (SRTP)", January 2013. 1079 17.2. Informative References 1081 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 1082 Relations among notions and analysis of the generic 1083 composition paradigm", Proceedings of ASIACRYPT 2000, 1084 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 1085 www-cse.ucsd.edu/users/mihir/papers/oem.html. 1087 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 1088 Recommendation for Block Cipher Modes of Operation: 1089 Galois/Counter Mode (GCM) and GMAC.", U.S. National 1090 Institute of Standards and Technology http:// 1091 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 1093 [R02] Rogaway, P., "Authenticated encryption with Associated- 1094 Data", ACM Conference on Computer and Communication 1095 Security (CCS'02), pp. 98-107, ACM Press, 1096 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 1098 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1099 Jacobson, "RTP: A Transport Protocol for Real-Time 1100 Applications", STD 64, RFC 3550, July 2003. 1102 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1103 Transform Carrying Roll-Over Counter for the Secure Real- 1104 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1106 Author's Address 1108 David A. McGrew 1109 Cisco Systems, Inc. 1110 510 McCarthy Blvd. 1111 Milpitas, CA 95035 1112 US 1113 Phone: (408) 525 8651 1114 Email: mcgrew@cisco.com 1115 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1117 Kevin M. Igoe 1118 NSA/CSS Commercial Solutions Center 1119 National Security Agency 1120 EMail: kmigoe@nsa.gov 1122 Acknowledgement 1124 Funding for the RFC Editor function is provided by the IETF 1125 Administrative Support Activity (IASA).