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