idnits 2.17.1 draft-ietf-avtcore-srtp-aes-gcm-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 21, 2014) is 3628 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 1110, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3610 Summary: 2 errors (**), 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: November 22, 2014 National Security Agency 5 May 21, 2014 7 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 8 draft-ietf-avtcore-srtp-aes-gcm-12 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 November 22, 2014. 27 Copyright Notice 29 Copyright (c) 2014 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 AES-GCM and AES-CCM Authenticated 45 Encryption with Associated Data algorithms can be used to provide 46 confidentiality and data authentication in the SRTP protocol. 48 Table of Contents 50 1. Introduction.....................................................3 51 2. Conventions Used In This Document................................4 52 3. Overview of the SRTP/SRTCP AEAD security Architecture............4 53 4. Terminology......................................................5 54 5. Generic AEAD Processing..........................................5 55 5.1. Types of Input Data.........................................5 56 5.2. AEAD Invocation Inputs and Outputs..........................5 57 5.2.1. Encrypt Mode...........................................6 58 5.2.2. Decrypt Mode...........................................6 59 5.3. Handling of AEAD Authentication.............................7 60 6. Counter Mode Encryption..........................................7 61 7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................8 62 8. Unneeded SRTP/SRTCP Fields.......................................8 63 8.1. SRTP/SRTCP Authentication Field.............................9 64 8.2. RTP Padding.................................................9 65 9. AES-GCM/CCM processing for SRTP..................................9 66 9.1. SRTP IV formation for AES-GCM and AES-CCM...................9 67 9.2. Data Types in SRTP Packets.................................10 68 9.3. Handling Header Extensions.................................11 69 9.4. Prevention of SRTP IV Reuse................................12 70 10. AES-GCM/CCM Processing of SRTCP Compound Packets...............13 71 10.1. SRTCP IV formation for AES-GCM and AES-CCM................13 72 10.2. Data Types in Encrypted SRTCP Compound Packets............14 73 10.3. Data Types in Unencrypted SRTCP Compound Packets..........15 74 10.4. Prevention of SRTCP IV Reuse..............................16 75 11. Constraints on AEAD for SRTP and SRTCP.........................16 76 12. Key Derivation Functions.......................................17 77 13. Summary of Algorithm Characteristics...........................17 78 13.1. AES-GCM for SRTP/SRTCP....................................17 79 13.2. AES-CCM for SRTP/SRTCP....................................20 80 14. Security Considerations........................................22 81 14.1. Handling of Security Critical Parameters..................23 82 14.2. Size of the Authentication Tag............................23 83 15. IANA Considerations............................................24 84 15.1. SDES......................................................25 85 15.2. DTLS......................................................25 86 15.3. MIKEY.....................................................28 87 15.4. AEAD registry.............................................29 88 16. Parameters for use with MIKEY..................................29 89 17. Acknowledgements...............................................30 90 18. References.....................................................31 91 18.1. Normative References......................................31 92 18.2. Informative References....................................32 94 1. Introduction 96 The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile 97 of the Real-time Transport Protocol (RTP) [RFC3550], which can 98 provide confidentiality, message authentication, and replay 99 protection to the RTP traffic and to the control traffic for RTP, the 100 Real-time Transport Control Protocol (RTCP). It is important to note 101 that the outgoing SRTP packets from a single endpoint may be 102 originating from several independent data sources. 104 Authenticated encryption [BN00] is a form of encryption that, in 105 addition to providing confidentiality for the plaintext that is 106 encrypted, provides a way to check its integrity and authenticity. 107 Authenticated Encryption with Associated Data, or AEAD [R02], adds 108 the ability to check the integrity and authenticity of some 109 Associated Data (AD), also called "additional authenticated data", 110 that is not encrypted. This specification makes use of the interface 111 to a generic AEAD algorithm as defined in [RFC5116]. 113 The Advanced Encryption Standard (AES) is a block cipher that 114 provides a high level of security, and can accept different key 115 sizes. Two families of AEAD algorithm families, AES Galois/Counter 116 Mode (AES-GCM) [GCM] and AES Counter with Cipher Block 117 Chaining-Message Authentication Code (AES-CCM) [RFC3610] are based 118 upon AES. This specification makes use of the AES versions that use 119 128-bit and 256-bit keys, which we call AES-128 and AES-256, 120 respectively. 122 Any AEAD algorithm provides an intrinsic authentication tag. In many 123 applications the authentication tag is truncated to less than full 124 length. This document only allows three values for the length of the 125 authentication tag: the length of the authentication tags MUST be 126 either 8 octets, 12 octets, or 16 octets in length. As with the size 127 of the key, the length of the authentication tag size is set when the 128 session is initiated and SHOULD NOT be altered. Thus each algorithm 129 AEAD will have a total of six configurations, reflecting the two 130 choices for key size (either 128 or 256 bits) and the three choices 131 for the length of the authentication tag (either 8, 12 or 16 132 octets). 134 The Galois/Counter Mode of operation (GCM) and the Counter with 135 Cipher Block Chaining-Message Authentication Code mode of operation 136 (CCM) are both AEAD modes of operation for block ciphers. Both use 137 counter mode to encrypt the data, an operation that can be 138 efficiently pipelined. Further, GCM authentication uses operations 139 that are particularly well suited to efficient implementation in 140 hardware, making it especially appealing for high-speed 141 implementations, or for implementations in an efficient and compact 142 circuit. CCM is well suited for use in compact software 143 implementations. This specification uses GCM and CCM with both 144 AES-128 and AES-256. 146 In summary, this document defines how to use AEAD algorithms, 147 particularly AES-GCM and AES-CCM, to provide confidentiality and 148 message authentication within SRTP and SRTCP packets. 150 2. Conventions Used In This Document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 [RFC2119]. 157 3. Overview of the SRTP/SRTCP AEAD security Architecture 159 SRTP/SRTCP AEAD security is based upon the following principles: 161 a) Both privacy and authentication are based upon the use of 162 symmetric algorithms. An AEAD algorithm such as AES-CCM or 163 AES-GCM combines privacy and authentication into a single 164 process. 166 b) A secret master key is shared by all participating endpoints, 167 both those originating SRTP/SRTCP packets and those receiving 168 these packets. Any given master key MAY be used 169 simultaneously by several endpoints to originate SRTP/SRTCP 170 packets (as well one or more endpoints using this master key 171 to process inbound data). 173 c) A Key Derivation Function is applied to the shared master key 174 value to form separate encryption keys, authentication keys 175 and salting keys for SRTP and for SRTCP (a total of six 176 keys). This process is described in section 4.3 of 177 [RFC3711]. Since AEAD algorithms such as AES-CCM and AES-GCM 178 combine encryption and authentication into a single process, 179 AEAD algorithms do not make use of the authentication keys. 180 The master key MUST be at least as large as the encryption 181 key derived from it. 183 d) Aside from making modifications to IANA registries to allow 184 AES-GCM and AES-CCM to work with SDES, DTLS and MIKEY, the 185 details of how the master key is established and shared 186 between the participants are outside the scope of this 187 document. Similarly any mechanism for rekeying an existing 188 session is outside the scope of the document. 190 e) Each time an instantiation of AES-GCM or AES-CCM is invoked 191 to encrypt and authenticate an SRTP or SRTCP data packet a 192 new IV is used. SRTP combines the 4-octet synchronization 193 source (SSRC) identifier, the 4-octet rollover counter (ROC), 194 and the 2-octet sequence number (SEQ) with the 12-octet 195 encryption salt to form a 12-octet IV (see section 9.1). 196 SRTCP combines the SSRC and 31-bit SRTCP index with the 197 encryption salt to form a 12-octet IV (see section 10.1). 199 4. Terminology 201 The following terms have very specific meanings in the context of 202 this RFC: 204 Instantiation: In AEAD, an instantiation is an (Encryption_key, 205 salt) pair together with all of the data 206 structures (for example, counters) needed for it 207 to function properly. In SRTP/SRTCP, each 208 endpoint will need two instantiations of the AEAD 209 algorithm for each master key in its possession, 210 one instantiation for SRTP traffic and one 211 instantiation for SRTCP traffic. 213 Invocation: SRTP/SRTCP data streams are broken into packets. 214 Each packet is processed by a single invocation 215 of the appropriate instantiation of the AEAD 216 algorithm. 218 In many applications, each endpoint will have one master key for 219 processing outbound data but may have one or more separate master 220 keys for processing inbound data. 222 5. Generic AEAD Processing 224 5.1. Types of Input Data 226 Associated Data: This is data that is to be authenticated 227 but not encrypted. 229 Plaintext: Data that is to be both encrypted and 230 authenticated. 232 Raw Data: Data that is to be neither encrypted nor 233 authenticated. 235 Which portions of SRTP/SRTCP packets that are to be treated as 236 associated data, which are to be treated as plaintext, and which are 237 to be treated as raw data are covered in sections 9.2, 10.2 and 238 10.3. 240 5.2. AEAD Invocation Inputs and Outputs 241 5.2.1. Encrypt Mode 243 Inputs: 244 Encryption_key Octet string, either 16 or 32 245 octets long 246 Initialization_Vector Octet string, 12 octets long 247 Associated_Data Octet string of variable length 248 Plaintext Octet string of variable length 249 Tag_Size_Flag (CCM only*) One Octet 251 Outputs 252 Ciphertext Octet string, length = 253 length(Plaintext)+tag_length 255 (*) CCM mode requires tag length to be explicitly input to 256 the algorithm, whereas with GCM, the tag is simply truncated. 257 For GCM, the algorithm choice determines the tag size. 259 In both CCM and GCM, the algorithm negotiation selects what tag size 260 is to be used. In GCM, the authentication tag is simply truncated to 261 the appropriate length, but CCM requires that the tag length be an 262 explicitly input to the algorithm as the Tag_Size_Field. For the 263 three tag lengths allowed in this document the corresponding 264 Tag_Size_Flag values are as follows: 266 Tag Length | Tag_Size_Flag (hex) 267 ----------------------------------- 268 8 octets | 5A 269 12 octets | 6A 270 16 octets | 7A 272 Once an SRTP/SRTCP session has been initiated the length of the tag 273 is a fixed value and MUST NOT be altered. 275 5.2.2. Decrypt Mode 277 Inputs: 278 Encryption_key Octet string, either 16 or 32 279 octets long 280 Initialization_Vector Octet string, 12 octets long 281 Associated_Data Octet string of variable length 282 Ciphertext Octet string of variable length 283 Tag_Size_Flag (CCM only*) One octet 285 Outputs 286 Plaintext Octet string, length = 287 length(Ciphertext)-tag_length 288 Validity_Flag Boolean, TRUE if valid, 289 FALSE otherwise 291 (*) For GCM, the algorithm choice determines the tag size. 293 As mentioned in section 5.2.1, only three tag lengths are supported 294 for use in SRTP/SRTCP, namely 8 octets, 12 octets and 16 octets. 296 5.3. Handling of AEAD Authentication 298 AEAD requires that all incoming packets MUST pass AEAD authentication 299 before any other action takes place. Plaintext and associated data 300 MUST NOT be released until the AEAD authentication tag has been 301 validated. Further the ciphertext MUST NOT be decrypted until the 302 AEAD tag has been validated. 304 Should the AEAD tag prove to be invalid, the packet in question is to 305 be discarded and a Validation Error flag raised. Local policy 306 determines how this flag is to be handled and is outside the scope of 307 this document. 309 6. Counter Mode Encryption 311 In both GCM and CCM, each outbound packet uses a 12-octet IV and an 312 encryption key to form two outputs, a 16-octet first_key_block which 313 is used in forming the authentication tag and a keystream of octets 314 which is XORed to the plaintext to form cipher. 316 When GCM is used, the concatenation of a 12-octet IV (see sections 317 9.1 and 10.1) with a 4-octet block counter forms the input to AES. 318 This is used to build a key_stream as follows: 320 def GCM_keystream( Plaintext_len, IV, Encryption_key ): 321 assert Plaintext_len <= (2**36) - 32 ## measured in octets 322 key_stream = "" 323 block_counter = 1 324 first_key_block = AES_ENC( data=IV||block_counter, 325 key=Encryption_key ) 326 while len(key_stream) < Plaintext_len: 327 block_counter = block_counter + 1 328 key_block = AES_ENC( data=IV||block_counter, 329 key=Encryption_key ) 330 key_stream = key_stream || key_block 331 key_stream = truncate( key_stream, Plaintext_len ) 332 return (first_key_block, key_stream ) 334 In AES-CCM counter mode encryption, the AES data input consists of 335 the concatenation of a 1-octet flag, a 12-octet IV, and a 3-octet 336 block counter. Note that in this application the flag octet will 337 always have the value 0x02 (see section 2.3 of [RFC3610]). A 338 (first_key_block, key_stream) pair is formed as follows: 340 def CCM_keystream( Plaintext_len, IV, Encryption_key ): 341 assert Plaintext_len <= (2**24)-1 ## measured in octets 342 key_stream = "" 343 block_counter = 0 344 first_key_block = AES_ENC( data=0x02||IV||block_counter, 345 key=Encryption_key ) 346 while len(key_stream)(+) 424 +--+--+--+--+--+--+--+--+--+--+--+--+ | 425 | 426 +--+--+--+--+--+--+--+--+--+--+--+--+ | 427 | Initialization Vector |<--+ 428 +--+--+--+--+--+--+--+--+--+--+--+--+ 430 Figure 1: AES-GCM and AES-CCM SRTP 431 Initialization Vector formation. 432 The 12 octet initialization vector used by both AES-GCM and AES-CCM 433 SRTP is formed by first concatenating 2-octets of zeroes, the 4-octet 434 SSRC, the 4-octet Rollover Counter (ROC) and the two octet sequence 435 number SEQ. The resulting 12-octet value is then XORed to the 436 12-octet salt to form the 12-octet IV. 438 9.2. Data Types in SRTP Packets 440 All SRTP packets MUST be both authenticated and encrypted. The data 441 fields within the SRTP packets are broken into Associated Data, 442 Plaintext and Raw Data as follows (see Figure 2): 444 Associated Data: The version V (2 bits), padding flag P (1 bit), 445 extension flag X (1 bit), CSRC count CC (4 bits), 446 marker M (1 bit), the Payload Type PT (8 bits), 447 the sequence number (16 bits), timestamp (32 448 bits), SSRC (32 bits), optional contributing 449 source identifiers (CSRCs, 32 bits each), and 450 optional RTP extension (variable length). 452 Plaintext: The RTP payload (variable length), RTP padding 453 (if used, variable length), and RTP pad count ( 454 if used, 1 octet). 456 Raw Data: The optional variable length SRTP MKI and SRTP 457 authentication tag (whose use is NOT 458 RECOMMENDED). These fields are appended after 459 encryption has been performed. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 A |V=2|P|X| CC |M| PT | sequence number | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 A | timestamp | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 A | synchronization source (SSRC) identifier | 469 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 470 A | contributing source (CSRC) identifiers (optional) | 471 A | .... | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 A | RTP extension (OPTIONAL) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 P | payload ... | 476 P | +-------------------------------+ 477 P | | RTP padding | RTP pad count | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 P = Plaintext (to be encrypted and authenticated) 481 A = Associated Data (to be authenticated only) 483 Figure 2: Structure of an SRTP packet before Authenticated 484 Encryption 486 Since the AEAD ciphertext is larger than the plaintext by exactly the 487 length of the AEAD authentication tag, the corresponding SRTP 488 encrypted packet replaces the plaintext field by a slightly larger 489 field containing the cipher. Even if the plaintext field is empty, 490 AEAD encryption must still be performed, with the resulting cipher 491 consisting solely of the authentication tag. This tag is to be 492 placed immediately before the optional SRTP MKI and SRTP 493 authentication tag fields. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 A |V=2|P|X| CC |M| PT | sequence number | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 A | timestamp | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 A | synchronization source (SSRC) identifier | 503 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 504 A | contributing source (CSRC) identifiers (optional) | 505 A | .... | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 A | RTP extension (OPTIONAL) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 C | cipher | 510 C | ... | 511 C | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 R : SRTP MKI (OPTIONAL) : 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 R : SRTP authentication tag (NOT RECOMMENDED) : 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 C = Cipertext (encrypted and authenticated) 519 A = Associated Data (authenticated only) 520 R = neither encrypted nor authenticated, added 521 after authenticated encryption completed 523 Figure 3: Structure of an SRTP packet after Authenticated 524 Encryption 526 9.3. Handling Header Extensions 528 RTP header extensions were first defined in RFC 3550. RFC 6904 529 [RFC6904] describes how these header extensions are to be encrypted 530 in SRTP. 532 When RFC 6904 is in use, a separate keystream is generated to encrypt 533 selected RTP header extension elements. For the AEAD_AES_128_GCM and 534 the AEAD_AES_128_CCM algorithms, this keystream MUST be generated in 535 the manner defined in [RFC6904] using the AES_128_CM transform. For 536 the AEAD_AES_256_GCM and the AEAD_AES_256_CCM algorithms, the 537 keystream MUST be generated in the manner defined for the AES_256_CM 538 transform. The originator must perform any required header extension 539 encryption before the AEAD algorithm is invoked. 541 As with the other fields contained within the RTP header, both 542 encrypted and unencrypted header extensions are to be treated by the 543 AEAD algorithm as Associated Data (AD). Thus the AEAD algorithm does 544 not provide any additional privacy for the header extensions, but 545 does provide integrity and authentication. 547 9.4. Prevention of SRTP IV Reuse 549 In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC) 550 triple is never used twice with the same master key. There are two 551 phases to this issue. 553 Counter Management: A rekey MUST be performed to establish a new 554 master key before the (ROC,SEQ) pair cycles 555 back to its original value. Note that 556 implicitly assumes that either the outgoing RTP 557 process is trusted to not attempt to repeat a 558 SEQ value, or that the encryption process 559 ensures that the SEQ number of the packets 560 presented to it are always incremented in the 561 proper fashion. This is particularly important 562 for GCM since using the same SEQ value twice 563 compromises the authentication mechanism. For 564 GCM, the SEQ and SSRC values used MUST either 565 be generated or checked by the SRTP 566 implementation, or by a module (e.g. the RTP 567 application) that can be considered equally 568 trusted as the SRTP implementation. While 569 [RFC3711] allows detecting SSRC collisions 570 after they happen, SRTP using GCM with shared 571 master keys MUST prevent SSRC collision from 572 happening even once. 574 SSRC Management: For a given master key, the set of all SSRC 575 values used with that master key must be 576 partitioned into disjoint pools, one pool for 577 each endpoint using that master key to 578 originate outbound data. Each such originating 579 endpoint MUST only issue SSRC values from the 580 pool it has been assigned. Further, each 581 originating endpoint MUST maintain a history of 582 outbound SSRC identifiers that it has issued 583 within the lifetime of the current master key, 584 and when a new synchronization source requests 585 an SSRC identifier it MUST NOT be given an 586 identifier that has been previously issued. A 587 rekey MUST be performed before any of the 588 originating endpoints using that master key 589 exhausts its pool of SSRC values. Further, the 590 identity of the entity giving out SSRC values 591 MUST be verified, and the SSRC signaling MUST 592 be integrity protected. 594 10. AES-GCM/CCM Processing of SRTCP Compound Packets 596 All SRTCP compound packets MUST be authenticated, but unlike SRTP, 597 SRTCP packet encryption is optional. A sender can select which 598 packets to encrypt, and indicates this choice with a 1-bit encryption 599 flag (located just before the 31-bit SRTCP index) 601 10.1. SRTCP IV formation for AES-GCM and AES-CCM 603 The 12-octet initialization vector used by both AES-GCM and AES-CCM 604 SRTCP is formed by first concatenating 2-octets of zeroes, the 605 4-octet Synchronization Source identifier (SSRC), 2-octets of zeroes, 606 a single zero bit, and the 31-bit SRTCP Index. The resulting 607 12-octet value is then XORed to the 12-octet salt to form the 608 12-octet IV. 610 0 1 2 3 4 5 6 7 8 9 10 11 611 +--+--+--+--+--+--+--+--+--+--+--+--+ 612 |00|00| SSRC |00|00|0+SRTCP Idx|---+ 613 +--+--+--+--+--+--+--+--+--+--+--+--+ | 614 | 615 +--+--+--+--+--+--+--+--+--+--+--+--+ | 616 | Encryption Salt |->(+) 617 +--+--+--+--+--+--+--+--+--+--+--+--+ | 618 | 619 +--+--+--+--+--+--+--+--+--+--+--+--+ | 620 | Initialization Vector |<--+ 621 +--+--+--+--+--+--+--+--+--+--+--+--+ 623 Figure 4: SRTCP Initialization Vector formation 625 10.2. Data Types in Encrypted SRTCP Compound Packets 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 A |V=2|P| RC | Packet Type | length | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 A | synchronization source (SSRC) of Sender | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 P | sender info : 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 P | report block 1 : 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 P | report block 2 : 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 P | ... : 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 P |V=2|P| SC | Packet Type | length | 643 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 644 P | SSRC/CSRC_1 | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 P | SDES items : 647 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 648 P | ... : 649 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 650 A |1| SRTCP index | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 R | SRTCP MKI (optional) index : 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 R : SRTCP authentication tag (NOT RECOMMENDED) : 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 P = Plaintext (to be encrypted and authenticated) 658 A = Associated Data (to be authenticated only) 659 R = neither encrypted nor authenticated, added after 660 encryption 662 Figure 5: AEAD SRTCP inputs when encryption flag = 1. 664 When the encryption flag is set to 1, the SRTCP packet is broken into 665 plaintext, associated data, and raw (untouched) data (as shown above 666 in figure 5): 668 Associated Data: The packet version V (2 bits), padding flag P (1 669 bit), reception report count RC (5 bits), packet 670 type (8 bits), length (2 octets), SSRC (4 671 octets), encryption flag (1 bit) and SRTCP index 672 (31 bits). 674 Raw Data: The 32-bit optional SRTCP MKI index and 32-bit 675 SRTCP authentication tag (whose use is NOT 676 RECOMMENDED). 678 Plaintext: All other data. 680 Note that the plaintext comes in one contiguous field. Since the 681 AEAD cipher is larger than the plaintext by exactly the length of the 682 AEAD authentication tag, the corresponding SRTCP encrypted packet 683 replaces the plaintext field with a slightly larger field containing 684 the cipher. Even if the plaintext field is empty, AEAD encryption 685 must still be performed, with the resulting cipher consisting solely 686 of the authentication tag. This tag is to be placed immediately 687 before the encryption flag and SRTCP index. 689 10.3. Data Types in Unencrypted SRTCP Compound Packets 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 A |V=2|P| RC | Packet Type | length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 A | synchronization source (SSRC) of Sender | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 A | sender info : 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 A | report block 1 : 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 A | report block 2 : 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 A | ... : 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 A |V=2|P| SC | Packet Type | length | 707 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 708 A | SSRC/CSRC_1 | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 A | SDES items : 711 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 712 A | ... : 713 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 714 A |0| SRTCP index | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 R | SRTCP MKI (optional)index : 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 R : authentication tag (NOT RECOMMENDED) : 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 A = Associated Data (to be authenticated only) 722 R = neither encrypted nor authenticated, added after 723 encryption 725 Figure 6: AEAD SRTCP inputs when encryption flag = 0 727 When the encryption flag is set to 0, the SRTCP compound packet is 728 broken into plaintext, associated data, and raw (untouched) data as 729 follows (see figure 6): 731 Plaintext: None. 733 Raw Data: The variable length optional SRTCP MKI index and 734 SRTCP authentication tag (whose use is NOT 735 RECOMMENDED). 737 Associated Data: All other data. 739 Even though there is no plaintext in this RTCP packet, AEAD 740 encryption returns a cipher field which is precisely the length of 741 the AEAD authentication tag. This cipher is to be placed before the 742 Encryption flag and the SRTCP index in the authenticated SRTCP 743 packet. 745 10.4. Prevention of SRTCP IV Reuse 747 A new master key MUST be established before the 31-bit SRTCP index 748 cycles back to its original value. Ideally, a rekey should be 749 performed and a new master key put in place well before the SRTCP 750 cycles back to the starting value. 752 The comments on SSRC management in section 9.4 also apply. 754 11. Constraints on AEAD for SRTP and SRTCP 756 In general, any AEAD algorithm can accept inputs with varying 757 lengths, but each algorithm can accept only a limited range of 758 lengths for a specific parameter. In this section, we describe the 759 constraints on the parameter lengths that any AEAD algorithm must 760 support to be used in AEAD-SRTP. Additionally, we specify a complete 761 parameter set for two specific AEAD algorithms, namely AES-GCM and 762 AES-CCM. 764 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the five 765 constraints listed below: 767 PARAMETER Meaning Value 769 A_MAX maximum associated MUST be at least 12 octets. 770 data length 771 N_MIN minimum nonce (IV) MUST be 12 octets. 772 length 773 N_MAX maximum nonce (IV) MUST be 12 octets. 774 length 775 P_MAX maximum plaintext GCM: MUST be <= 2^36-32 octets. 776 length per invocation CCM: MUST be <= 2^24-1 octets. 778 C_MAX maximum ciphertext GCM: MUST be <= 2^36-16 octets. 779 length per invocation CCM: MUST be <= 2^24+15 octets. 781 For GCM the value of P_MAX is based on purely cryptographic 782 considerations. CCM requires the lenght of the plaintext, measured 783 in octets, must fit in a 24-bit field. Hence P_MAX is 2^24-1.. 785 For sake of clarity we specify two additional parameters: 787 AEAD Authentication Tag Length MUST be either 8, 12, or 16 788 octets 789 Maximum number of invocations MUST be at most 2^48 for SRTP 790 for a given instantiation MUST be at most 2^31 for SRTCP 791 Block Counter size MUST be 24 bits for CCM, 792 MUST be 32 bits for GCM 794 The reader is reminded that the ciphertext is longer than the 795 plaintext by exactly the length of the AEAD authentication tag. 797 12. Key Derivation Functions 799 A Key Derivation Function (KDF) is used to derive all of the required 800 encryption and authentication keys from a secret value shared by the 801 endpoints. Both the AEAD_AES_128_GCM algorithms and the 802 AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key 803 Derivation Function described in [RFC3711]. Both the 804 AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST 805 use the AES_256_CM_PRF Key Derivation Function described in 806 [RFC6188]. 808 13. Summary of Algorithm Characteristics 810 For convenience, much of the information about the use of AES-GCM and 811 AES-CCM algorithms in SRTP is collected in the tables contained in 812 this section. 814 13.1. AES-GCM for SRTP/SRTCP 816 AES-GCM is a family of AEAD algorithms built around the AES block 817 cipher algorithm. AES-GCM uses AES counter mode for encryption and 818 Galois Message Authentication Code (GMAC) for authentication. A 819 detailed description of the AES-GCM family can be found in 820 [RFC5116]. The following members of the AES-GCM family may be used 821 with SRTP/SRTCP: 823 Name Key Size AEAD Tag Size Reference 824 ================================================================ 825 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 826 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 827 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 828 AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] 829 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 830 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 832 Table 1: AES-GCM algorithms for SRTP/SRTCP 834 Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM 835 and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication 836 tags), and it MAY support the four other variants shown in table 1. 837 Below we summarize parameters associated with these six GCM 838 algorithms: 840 +--------------------------------+------------------------------+ 841 | Parameter | Value | 842 +--------------------------------+------------------------------+ 843 | Master key length | 128 bits | 844 | Master salt length | 96 bits | 845 | Key Derivation Function | AES_CM_PRF [RFC3711] | 846 | Default key lifetime (SRTP) | 2^48 packets | 847 | Default key lifetime (SRTCP) | 2^31 packets | 848 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_GCM_8 | 849 | AEAD authentication tag length | 64 bits | 850 +--------------------------------+------------------------------+ 852 Table 2: The AEAD_AES_128_GCM_8 Crypto Suite 854 +--------------------------------+------------------------------+ 855 | Parameter | Value | 856 +--------------------------------+------------------------------+ 857 | Master key length | 128 bits | 858 | Master salt length | 96 bits | 859 | Key Derivation Function | AES_CM_PRF [RFC3711] | 860 | Default key lifetime (SRTP) | 2^48 packets | 861 | Default key lifetime (SRTCP) | 2^31 packets | 862 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_GCM_12 | 863 | AEAD authentication tag length | 96 bits | 864 +--------------------------------+------------------------------+ 866 Table 3: The AEAD_AES_128_GCM_12 Crypto Suite 868 +--------------------------------+------------------------------+ 869 | Parameter | Value | 870 +--------------------------------+------------------------------+ 871 | Master key length | 128 bits | 872 | Master salt length | 96 bits | 873 | Key Derivation Function | AES_CM_PRF [RFC3711] | 874 | Default key lifetime (SRTP) | 2^48 packets | 875 | Default key lifetime (SRTCP) | 2^31 packets | 876 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_GCM | 877 | AEAD authentication tag length | 128 bits | 878 +--------------------------------+------------------------------+ 880 Table 4: The AEAD_AES_128_GCM Crypto Suite 882 +--------------------------------+------------------------------+ 883 | Parameter | Value | 884 +--------------------------------+------------------------------+ 885 | Master key length | 256 bits | 886 | Master salt length | 96 bits | 887 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 888 | Default key lifetime (SRTP) | 2^17 packets | 889 | Default key lifetime (SRTCP) | 2^17 packets | 890 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_GCM_8 | 891 | AEAD authentication tag length | 64 bits | 892 +--------------------------------+------------------------------+ 894 Table 5: The AEAD_AES_256_GCM_8 Crypto Suite 896 +--------------------------------+------------------------------+ 897 | Parameter | Value | 898 +--------------------------------+------------------------------+ 899 | Master key length | 256 bits | 900 | Master salt length | 96 bits | 901 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 902 | Default key lifetime (SRTP) | 2^48 packets | 903 | Default key lifetime (SRTCP) | 2^31 packets | 904 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_GCM_12 | 905 | AEAD authentication tag length | 96 bits | 906 +--------------------------------+------------------------------+ 908 Table 6: The AEAD_AES_256_GCM_12 Crypto Suite 910 +--------------------------------+------------------------------+ 911 | Parameter | Value | 912 +--------------------------------+------------------------------+ 913 | Master key length | 256 bits | 914 | Master salt length | 96 bits | 915 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 916 | Default key lifetime (SRTP) | 2^48 packets | 917 | Default key lifetime (SRTCP) | 2^31 packets | 918 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_GCM | 919 | AEAD authentication tag length | 128 bits | 920 +--------------------------------+------------------------------+ 921 Table 7: The AEAD_AES_256_GCM Crypto Suite 923 13.2. AES-CCM for SRTP/SRTCP 925 AES-CCM is another family of AEAD algorithms built around the AES 926 block cipher algorithm. AES-CCM uses AES counter mode for encryption 927 and AES Cipher Block Chaining Message Authentication Code (CBC-MAC) 928 for authentication. A detailed description of the AES-CCM family can 929 be found in [RFC5116]. Four of the six CCM algorithms used in this 930 document are defined in previous RFCs, while two, AEAD_AES_128_CCM_12 931 and AEAD_AES_256_CCM_12, are defined in section 7 of this document. 933 Any implementation of AES-CCM SRTP/SRTCP MUST support both 934 AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet 935 AEAD authentication tags), and MAY support the other four variants. 937 Name Key Size AEAD Tag Size Reference 938 ================================================================ 939 AEAD_AES_128_CCM 128 bits 16 octets [RFC5116] 940 AEAD_AES_256_CCM 256 bits 16 octets [RFC5116] 941 AEAD_AES_128_CCM_12 128 bits 12 octets see section 7 942 AEAD_AES_256_CCM_12 256 bits 12 octets see section 7 943 AEAD_AES_128_CCM_8 128 bits 8 octets [RFC6655] 944 AEAD_AES_256_CCM_8 256 bits 8 octets [RFC6655] 946 Table 8: AES-CCM algorithms for SRTP/SRTCP 948 In addition to the flag octet used in counter mode encryption, 949 AES-CCM authentications also uses a flag octet that conveys 950 information about the length of the authentication tag, length of the 951 block counter, and presence of additional authenticated data (see 952 section 2.2 of [RFC3610]). For AES-CCM in SRTP/SRTCP, the flag octet 953 has the hex value 5A if an 8-octet AEAD authentication tag is used, 954 6A if a 12-octet AEAD authentication tag is used, and 7A if a 955 16-octet AEAD authentication tag is used. The flag octet is one of 956 the inputs to AES during the counter mode encryption of the 957 plaintext. 959 +--------------------------------+------------------------------+ 960 | Parameter | Value | 961 +--------------------------------+------------------------------+ 962 | Master key length | 128 bits | 963 | Master salt length | 96 bits | 964 | Key Derivation Function | AES_CM_PRF [RFC3711] | 965 | Maximum key lifetime (SRTP) | 2^48 packets | 966 | Maximum key lifetime (SRTCP) | 2^31 packets | 967 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_CCM_8 | 968 | AEAD authentication tag length | 64 bits | 969 +--------------------------------+------------------------------+ 971 Table 9: The AEAD_AES_128_CCM_8 Crypto Suite 973 +--------------------------------+------------------------------+ 974 | Parameter | Value | 975 +--------------------------------+------------------------------+ 976 | Master key length | 128 bits | 977 | Master salt length | 96 bits | 978 | Key Derivation Function | AES_CM_PRF [RFC3711] | 979 | Maximum key lifetime (SRTP) | 2^48 packets | 980 | Maximum key lifetime (SRTCP) | 2^31 packets | 981 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_CCM_12 | 982 | AEAD authentication tag length | 96 bits | 983 +--------------------------------+------------------------------+ 985 Table 10: The AEAD_AES_128_CCM_12 Crypto Suite 987 +--------------------------------+------------------------------+ 988 | Parameter | Value | 989 +--------------------------------+------------------------------+ 990 | Master key length | 128 bits | 991 | Master salt length | 96 bits | 992 | Key Derivation Function | AES_CM_PRF [RFC3711] | 993 | Maximum key lifetime (SRTP) | 2^48 packets | 994 | Maximum key lifetime (SRTCP) | 2^31 packets | 995 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_CCM | 996 | AEAD authentication tag length | 128 bits | 997 +--------------------------------+------------------------------+ 999 Table 11: The AEAD_AES_128_CCM Crypto Suite 1001 +--------------------------------+------------------------------+ 1002 | Parameter | Value | 1003 +--------------------------------+------------------------------+ 1004 | Master key length | 256 bits | 1005 | Master salt length | 96 bits | 1006 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 1007 | Maximum key lifetime (SRTP) | 2^48 packets | 1008 | Maximum key lifetime (SRTCP) | 2^31 packets | 1009 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_CCM_8 | 1010 | AEAD authentication tag length | 64 bits | 1011 +--------------------------------+------------------------------+ 1013 Table 12: The AEAD_AES_256_CCM_8 Crypto Suite 1015 +--------------------------------+------------------------------+ 1016 | Parameter | Value | 1017 +--------------------------------+------------------------------+ 1018 | Master key length | 256 bits | 1019 | Master salt length | 96 bits | 1020 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 1021 | Maximum key lifetime (SRTP) | 2^48 packets | 1022 | Maximum key lifetime (SRTCP) | 2^31 packets | 1023 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_CCM_12 | 1024 | AEAD authentication tag length | 96 bits | 1025 +--------------------------------+------------------------------+ 1027 Table 13: The AEAD_AES_256_CCM_12 Crypto Suite 1029 +--------------------------------+------------------------------+ 1030 | Parameter | Value | 1031 +--------------------------------+------------------------------+ 1032 | Master key length | 256 bits | 1033 | Master salt length | 96 bits | 1034 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 1035 | Maximum key lifetime (SRTP) | 2^48 packets | 1036 | Maximum key lifetime (SRTCP) | 2^31 packets | 1037 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_CCM | 1038 | AEAD authentication tag length | 128 bits | 1039 +--------------------------------+------------------------------+ 1041 Table 14: The AEAD_AES_256_CCM Crypto Suite 1043 14. Security Considerations 1044 14.1. Handling of Security Critical Parameters 1046 As with any security process, the implementer must take care to 1047 ensure cryptographically sensitive parameters are properly handled. 1048 Many of these recommendations hold for all SRTP cryptographic 1049 algorithms, but we include them here to emphasize their importance. 1051 - If the master salt is to be kept secret, it MUST be properly 1052 erased when no longer needed. 1053 - The secret master key and all keys derived from it MUST be kept 1054 secret. All keys MUST be properly erased when no longer 1055 needed. 1056 - At the start of each packet, the block counter MUST be reset (to 1057 0 for CCM, to 1 for GCM). The block counter is incremented 1058 after each block key has been produced, but it MUST NOT be 1059 allowed to exceed 2^32-1 for GCM and 2^24-1 for CCM. Note that 1060 even though the block counter is reset at the start of each 1061 packet, IV uniqueness is ensured by the inclusion of 1062 SSRC/ROC/SEQ or SRTCP Index in the IV. (The reader is reminded 1063 that in both GCM and CCM the first block of key produced is 1064 reserved for use in authenticating the packet and is not used to 1065 encrypt plaintext.) 1066 - Each time a rekey occurs, the initial values of the SRTCP index 1067 and the SRTP packet indices MUST be saved in order to prevent IV 1068 reuse. 1069 - Processing MUST cease if the 31-bit SRTCP index or any of the 1070 48-bit packet indices cycle back their initial values . 1071 Processing MUST NOT resume until a new SRTP/SRTCP session has 1072 been established using a new SRTP master key. Ideally, a rekey 1073 should be done well before any of these counters cycle. 1075 14.2. Size of the Authentication Tag 1077 We require that the AEAD authentication tag must be at least 8 1078 octets, significantly reducing the probability of an adversary 1079 successfully introducing fraudulent data. The goal of an 1080 authentication tag is to reduce the probability of a successful 1081 forgery occurring anywhere in the network we are attempting to 1082 defend. There are three relevant factors: how low we wish the 1083 probability of successful forgery to be (prob_success), how many 1084 attempts the adversary can make (N_tries) and the size of the 1085 authentication tag in bits (N_tag_bits). Then 1087 prob_success <= expected number of successes 1088 = N_tries * 2^-N_tag_bits. 1090 When the expected number of successes is much less than one, the 1091 probability of success is well approximated by the expected number of 1092 successes. 1094 Suppose an adversary wishes to introduce a forged or altered packet 1095 into a target network by randomly selecting an authentication value 1096 until by chance they hit a valid authentication tag. The table below 1097 summarizes the relationship between the number of forged packets the 1098 adversary has tried, the size of the authentication tag, and the 1099 probability of a compromise occurring (i.e. at least one of the 1100 attempted forgeries having a valid authentication tag). The reader 1101 is reminded that the forgery attempts can be made over the entire 1102 network, not just a single link, and that frequently changing the key 1103 does not decrease the probability of a compromise occurring. 1105 It should be noted that the cryptographic properties of the GHASH 1106 algorithm used in GCM reduces the effective authentication tag size 1107 (in bits) by the log base 2 of the of blocks of encrypted and/or 1108 authenticated data in a packet. In practice an SRTP payload will be 1109 less than 2^16 bytes, because of the 16-bit IPv4 and UDP length 1110 fields. The exception to this case is IPv6 jumbograms [RFC2675], 1111 which is unlikely to be used for RTP-based multimedia traffic 1112 [RFC3711]. This corresponds to 2^12 blocks of data, so the effective 1113 GCM authentication tag size is reduced by at most 12 bits. 1115 +===========+=============+========================================+ 1116 | Auth. Tag | Eff. Tag | Number of Forgery Attempts | 1117 | Size | Tag Size | Needed to Achieve a Given | 1118 | (bytes) | (bits) | Probability of Success | 1119 |-----------+-------------+------------+-------------+-------------| 1120 | | prob=2^-30 | prob=2^-20 | prob=2^-10 | 1121 |===========+=============+=============+============+=============| 1122 | | 32 (CCM) | 2^2 tries | 2^12 tries | 2^22 tries | 1123 | 4 +-------------+------------+-------------+-------------| 1124 | | 20 (GCM) | 1 try | 1 try | 2^10 tries | 1125 |===========+=============+============+=============+=============| 1126 | | 64 (CCM) | 2^34 tries | 2^44 tries | 2^54 tries | 1127 | 8 +-------------+------------+-------------+-------------| 1128 | | 52 (GCM) | 2^22 tries | 2^32 tries | 2^42 tries | 1129 |===========+=============+============+=============+=============| 1130 | | 96 (CCM) | 2^66 tries | 2^76 tries | 2^86 tries | 1131 | 12 +-------------+------------+-------------+-------------| 1132 | | 84 (GCM) | 2^54 tries | 2^64 tries | 2^74 tries | 1133 |===========+=============+============+=============+=============| 1134 | | 128 (CCM) | 2^86 tries | 2^96 tries | 2^106 tries | 1135 | 16 +-------------+------------+-------------+-------------| 1136 | | 116 (GCM) | 2^98 tries | 2^108 tries | 2^118 tries | 1137 |===========+=============+============+=============+=============| 1139 Table 15: Number of forgery attempts needed to achieve a given 1140 probability of success for various tag sizes. 1142 15. IANA Considerations 1143 15.1. SDES 1145 SDP Security Descriptions [RFC4568] defines SRTP "crypto suites". A 1146 crypto suite corresponds to a particular AEAD algorithm in SRTP. In 1147 order to allow Security Descriptions to signal the use of the 1148 algorithms defined in this document, IANA will register the following 1149 crypto suites into the "SRTP Crypto Suite Registrations" subregistry 1150 of the "Session Description Protocol (SDP) Security Descriptions" 1151 registry. 1153 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 1154 "AEAD_AES_256_GCM" / 1155 "AEAD_AES_128_GCM_8" / 1156 "AEAD_AES_256_GCM_8" / 1157 "AEAD_AES_128_GCM_12" / 1158 "AEAD_AES_256_GCM_12" / 1159 "AEAD_AES_128_CCM" / 1160 "AEAD_AES_256_CCM" / 1161 "AEAD_AES_128_CCM_8" / 1162 "AEAD_AES_256_CCM_8" / 1163 "AEAD_AES_128_CCM_12" / 1164 "AEAD_AES_256_CCM_12" / 1165 srtp-crypto-suite-ext 1167 15.2. DTLS 1169 DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile". 1170 These also correspond to the use of an AEAD algorithm in SRTP. In 1171 order to allow the use of the algorithms defined in this document in 1172 DTLS-SRTP, we request IANA register the following SRTP Protection 1173 Profiles: 1175 AEAD_AES_128_GCM = {TBD, TBD } 1176 AEAD_AES_256_GCM = {TBD, TBD } 1177 AEAD_AES_128_GCM_8 = {TBD, TBD } 1178 AEAD_AES_256_GCM_8 = {TBD, TBD } 1179 AEAD_AES_128_GCM_12 = {TBD, TBD } 1180 AEAD_AES_256_GCM_12 = {TBD, TBD } 1181 AEAD_AES_128_CCM = {TBD, TBD } 1182 AEAD_AES_256_CCM = {TBD, TBD } 1183 AEAD_AES_128_CCM_8 = {TBD, TBD } 1184 AEAD_AES_256_CCM_8 = {TBD, TBD } 1185 AEAD_AES_128_CCM_12 = {TBD, TBD } 1186 AEAD_AES_256_CCM_12 = {TBD, TBD } 1188 Below we list the SRTP transform parameters for each of these 1189 protection profile. Unless separate parameters for SRTCP and SRTCP 1190 are explicitly listed, these parameters apply to both SRTP and 1191 SRTCP. Note that GCM with an 8 octet auth_tag_length has a smaller 1192 than anticipated maximum lifetime due to the constraints imposed by 1193 NIST SP 800-38D appendix C. 1195 AEAD_AES_128_CCM 1196 cipher: AES_128_CCM 1197 cipher_key_length: 128 bits 1198 cipher_salt_length: 96 bits 1199 aead_auth_tag_length: 16 octets 1200 auth_function: NULL 1201 auth_key_length: N/A 1202 auth_tag_length: N/A 1203 maximum lifetime: at most 2^31 SRTCP packets and 1204 at most 2^48 SRTP packets 1206 AEAD_AES_256_CCM 1207 cipher: AES_256_CCM 1208 cipher_key_length: 256 bits 1209 cipher_salt_length: 96 bits 1210 aead_auth_tag_length: 16 octets 1211 auth_function: NULL 1212 auth_key_length: N/A 1213 auth_tag_length: N/A 1214 maximum lifetime: at most 2^31 SRTCP packets and 1215 at most 2^48 SRTP packets 1217 AEAD_AES_128_CCM_8 1218 cipher: AES_128_CCM 1219 cipher_key_length: 128 bits 1220 cipher_salt_length: 96 bits 1221 aead_auth_tag_length: 8 octets 1222 auth_function: NULL 1223 auth_key_length: N/A 1224 auth_tag_length: N/A 1225 maximum lifetime: at most 2^31 SRTCP packets and 1226 at most 2^48 SRTP packets 1228 AEAD_AES_256_CCM_8 1229 cipher: AES_256_CCM 1230 cipher_key_length: 256 bits 1231 cipher_salt_length: 96 bits 1232 aead_auth_tag_length: 8 octets 1233 auth_function: NULL 1234 auth_key_length: N/A 1235 auth_tag_length: N/A 1236 maximum lifetime: at most 2^31 SRTCP packets and 1237 at most 2^48 SRTP packets 1239 AEAD_AES_128_CCM_12 1240 cipher: AES_128_CCM 1241 cipher_key_length: 128 bits 1242 cipher_salt_length: 96 bits 1243 aead_auth_tag_length: 12 octets 1244 auth_function: NULL 1245 auth_key_length: N/A 1246 auth_tag_length: N/A 1247 maximum lifetime: at most 2^31 SRTCP packets and 1248 at most 2^48 SRTP packets 1250 AEAD_AES_256_CCM_12 1251 cipher: AES_256_CCM 1252 cipher_key_length: 256 bits 1253 cipher_salt_length: 96 bits 1254 aead_auth_tag_length: 12 octets 1255 auth_function: NULL 1256 auth_key_length: N/A 1257 auth_tag_length: N/A 1258 maximum lifetime: at most 2^31 SRTCP packets and 1259 at most 2^48 SRTP packets 1261 AEAD_AES_128_GCM 1262 cipher: AES_128_GCM 1263 cipher_key_length: 128 bits 1264 cipher_salt_length: 96 bits 1265 aead_auth_tag_length: 16 octets 1266 auth_function: NULL 1267 auth_key_length: N/A 1268 auth_tag_length: N/A 1269 maximum lifetime: at most 2^31 SRTCP packets and 1270 at most 2^48 SRTP packets 1272 AEAD_AES_256_GCM 1273 cipher: AES_256_GCM 1274 cipher_key_length: 256 bits 1275 cipher_salt_length: 96 bits 1276 aead_auth_tag_length: 16 octets 1277 auth_function: NULL 1278 auth_key_length: N/A 1279 auth_tag_length: N/A 1280 maximum lifetime: at most 2^31 SRTCP packets and 1281 at most 2^48 SRTP packets 1283 AEAD_AES_128_GCM_8 1284 cipher: AES_128_GCM 1285 cipher_key_length: 128 bits 1286 cipher_salt_length: 96 bits 1287 aead_auth_tag_length: 8 octets 1288 auth_function: NULL 1289 auth_key_length: N/A 1290 auth_tag_length: N/A 1291 maximum lifetime: at most 2^17 SRTCP packets and 1292 at most 2^17 SRTP packets 1294 AEAD_AES_256_GCM_8 1295 cipher: AES_256_GCM 1296 cipher_key_length: 256 bits 1297 cipher_salt_length: 96 bits 1298 aead_auth_tag_length: 8 octets 1299 auth_function: NULL 1300 auth_key_length: N/A 1301 auth_tag_length: N/A 1302 maximum lifetime: at most 2^17 SRTCP packets and 1303 at most 2^17 SRTP packets 1305 AEAD_AES_128_GCM_12 1306 cipher: AES_128_GCM 1307 cipher_key_length: 128 bits 1308 cipher_salt_length: 96 bits 1309 aead_auth_tag_length: 12 octets 1310 auth_function: NULL 1311 auth_key_length: N/A 1312 auth_tag_length: N/A 1313 maximum lifetime: at most 2^31 SRTCP packets and 1314 at most 2^48 SRTP packets 1316 AEAD_AES_256_GCM_12 1317 cipher: AES_256_GCM 1318 cipher_key_length: 256 bits 1319 cipher_salt_length: 96 bits 1320 aead_auth_tag_length: 12 octets 1321 auth_function: NULL 1322 auth_key_length: N/A 1323 auth_tag_length: N/A 1324 maximum lifetime: at most 2^31 SRTCP packets and 1325 at most 2^48 SRTP packets 1327 Note that these SRTP Protection Profiles do not specify an 1328 auth_function, auth_key_length, or auth_tag_length because all of 1329 these profiles use AEAD algorithms, and thus do not use a separate 1330 auth_function, auth_key, or auth_tag. The term aead_auth_tag_length 1331 is used to emphasize that this refers to the authentication tag 1332 provided by the AEAD algorithm and that this tag is not located in 1333 the authentication tag field provided by SRTP/SRTCP. 1335 15.3. MIKEY 1337 In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], 1338 IANA maintains several subregitries under "Multimedia Internet KEYing 1339 (MIKEY) Payload Name Spaces". This document requires additions to 1340 two of the MIKEY subregistries. 1342 In the "MIKEY Security Protocol Parameters" subregistry we request 1343 the following addition: 1345 Type | Meaning | Possible values 1346 ---------------------------------------------------------------- 1347 TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) 1349 This list is, of course, intended for use with CM and GCM. It is 1350 conceivable that new AEAD algorithms introduced at some point in the 1351 future may require a different set of Authentication tag lengths. 1353 In the "Encryption Algorithm" subregistry (derived from Table 1354 6.10.1.b of [RFC3830]) we request the following additions: 1356 SRTP encr | Value | Default Session | Default Auth. 1357 Algorithm | | Encr. Key Length | Tag Length 1358 ----------------------------------------------------------- 1359 AES-CCM | TBD | 16 octets | 16 octets 1360 AES-GCM | TBD | 16 octets | 16 octets 1362 The SRTP encryption algorithm, session encryption key length, and 1363 AEAD authentication tag values received from MIKEY fully determine 1364 the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is 1365 described in section 16. 1367 15.4. AEAD registry 1369 We request that IANA make the following additions to the IANA 1370 "Authenticated Encryption with Associated Data (AEAD) Parameters" 1371 page's registry for "AEAD Algorithms": 1373 AEAD_AES_128_CCM_12 = TBD 1374 AEAD_AES_256_CCM_12 = TBD 1376 16. Parameters for use with MIKEY 1378 MIKEY specifies the algorithm family separately from the key length 1379 (which is specified by the Session Encryption key length) and the 1380 authentication tag length (specified by AEAD Auth. tag length). 1382 +------------+-------------+-------------+ 1383 | Encryption | Encryption | AEAD Auth. | 1384 | Algorithm | Key Length | Tag Length | 1385 +============+=============+=============+ 1386 AEAD_AES_128_GCM | AES-GCM | 16 octets | 16 octets | 1387 +------------+-------------+-------------+ 1388 AEAD_AES_128_CCM | AES-CCM | 16 octets | 16 octets | 1389 +------------+-------------+-------------+ 1390 AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets | 1391 +------------+-------------+-------------+ 1392 AEAD_AES_128_CCM_12 | AES-CCM | 16 octets | 12 octets | 1393 +------------+-------------+-------------+ 1394 AEAD_AES_128_GCM_8 | AES-GCM | 16 octets | 8 octets | 1395 +------------+-------------+-------------+ 1396 AEAD_AES_128_CCM_8 | AES-CCM | 16 octets | 8 octets | 1397 +------------+-------------+-------------+ 1398 AEAD_AES_256_GCM | AES-GCM | 32 octets | 16 octets | 1399 +------------+-------------+-------------+ 1400 AEAD_AES_256_CCM | AES-CCM | 32 octets | 16 octets | 1401 +------------+-------------+-------------+ 1402 AEAD_AES_256_GCM_12 | AES-GCM | 32 octets | 12 octets | 1403 +------------+-------------+-------------+ 1404 AEAD_AES_256_CCM_12 | AES-CCM | 32 octets | 12 octets | 1405 +------------+-------------+-------------+ 1406 AEAD_AES_256_GCM_8 | AES-GCM | 32 octets | 8 octets | 1407 +------------+-------------+-------------+ 1408 AEAD_AES_256_CCM_8 | AES-CCM | 32 octets | 8 octets | 1409 +============+=============+=============+ 1411 Table 16: Mapping MIKEY parameters to AEAD algorithm 1413 Section 12 in this document restricts the choice of Key Derivation 1414 Function for AEAD algorithms. To enforce this restriction in MIKEY, 1415 we require that the SRTP PRF has value AES-CM whenever an AEAD 1416 algorithm is used. Note that, according to Section 6.10.1 in 1417 [RFC3830], the input key length of the Key Derivation Function (i.e. 1418 the SRTP master key length) is always equal to the session encryption 1419 key length. This means, for example, that AEAD_AES_256_GCM will use 1420 AES_256_CM_PRF as the Key Derivation Function. 1422 17. Acknowledgements 1424 The authors would like to thank Michael Peck, Michael Torla, Qin Wu, 1425 Magnus Westerland, Oscar Ohllson, Woo-Hwan Kim, John Mattsson, 1426 Richard Barnes, John Mattisson, Morris Dworkin and many other 1427 reviewers who provided valuable comments on earlier drafts of this 1428 document. 1430 18. References 1432 18.1. Normative References 1434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1435 Requirement Levels", BCP 14, RFC 2119, March 1997. 1437 [RFC3550] Casner, S., Frederick, R., and V. Jacobson, "RTP: A 1438 Transport Protocol for Real-Time Applications", RFC 3550, 1439 July 2003. 1441 [RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with 1442 CBC-MAC (CCM)", RFC 3610, March 2004. 1444 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 1445 K. Norrman, "The Secure Real-time Transport Protocol 1446 (SRTP)", RFC 3711, September 2003. 1448 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and 1449 Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1450 August 2004. 1452 [RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session 1453 Description Protocol (SDP): Security Descriptions for 1454 Media Streams", RFC 4568, July 2006. 1456 [RFC5116] McGrew, D., "An Interface and Algorithms for 1457 Authenticated Encryption with Associated Data", RFC 5116, 1458 January 2008. 1460 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 1461 Algorithms with the Encrypted Payload of the Internet Key 1462 Exchange version 2 (IKEv2) Protocol", RFC 5282, 1463 August 2008. 1465 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1466 Security (DTLS) Extension to Establish Keys for the Secure 1467 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1469 [RFC6188] D. McGrew, "The Use of AES-192 and AES-256 in Secure 1470 RTP", RFC 6188, March 2011. 1472 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1473 Transport Layer Security (TLS)", RFC 6655, July 2012. 1475 [RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure 1476 Real-Time Transport Protocol (SRTP)", January 2013. 1478 , January 2013. 1480 [RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure 1481 Real-Time Transport Protocol (SRTP)", January 2013. 1483 18.2. Informative References 1485 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 1486 Relations among notions and analysis of the generic 1487 composition paradigm", Proceedings of ASIACRYPT 2000, 1488 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 1489 www-cse.ucsd.edu/users/mihir/papers/oem.html. 1491 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 1492 Recommendation for Block Cipher Modes of Operation: 1493 Galois/Counter Mode (GCM) and GMAC.", U.S. National 1494 Institute of Standards and Technology http:// 1495 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 1497 [R02] Rogaway, P., "Authenticated encryption with Associated- 1498 Data", ACM Conference on Computer and Communication 1499 Security (CCS'02), pp. 98-107, ACM Press, 1500 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 1502 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1503 Jacobson, "RTP: A Transport Protocol for Real-Time 1504 Applications", STD 64, RFC 3550, July 2003. 1506 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1507 Transform Carrying Roll-Over Counter for the Secure Real- 1508 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1510 Author's Address 1512 David A. McGrew 1513 Cisco Systems, Inc. 1514 510 McCarthy Blvd. 1515 Milpitas, CA 95035 1516 US 1517 Phone: (408) 525 8651 1518 Email: mcgrew@cisco.com 1519 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1521 Kevin M. Igoe 1522 NSA/CSS Commercial Solutions Center 1523 National Security Agency 1524 EMail: kmigoe@nsa.gov 1526 Acknowledgement 1528 Funding for the RFC Editor function is provided by the IETF 1529 Administrative Support Activity (IASA).