idnits 2.17.1 draft-ietf-avtcore-srtp-aes-gcm-13.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 (June 23, 2014) is 3594 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 1088, 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: December 25, 2014 National Security Agency 5 June 23, 2014 7 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 8 draft-ietf-avtcore-srtp-aes-gcm-13 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 December 25, 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..........................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......................................................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 and MIKEY, the 189 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 (8 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 SRTP MKI and SRTP 500 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 32-bit optional SRTCP MKI index and 32-bit 682 SRTCP 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 R | SRTCP MKI (optional)index : 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 R : authentication tag (NOT RECOMMENDED) : 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 A = Associated Data (to be authenticated only) 729 R = neither encrypted nor authenticated, added after 730 encryption 732 Figure 6: AEAD SRTCP inputs when encryption flag = 0 734 When the encryption flag is set to 0, the SRTCP compound packet is 735 broken into plaintext, associated data, and raw (untouched) data as 736 follows (see figure 6): 738 Plaintext: None. 740 Raw Data: The variable length optional SRTCP MKI index and 741 SRTCP authentication tag (whose use is NOT 742 RECOMMENDED). 744 Associated Data: All other data. 746 Even though there is no plaintext in this RTCP packet, AEAD 747 encryption returns a cipher field which is precisely the length of 748 the AEAD authentication tag. This cipher is to be placed before the 749 Encryption flag and the SRTCP index in the authenticated SRTCP 750 packet. 752 10.4. Prevention of SRTCP IV Reuse 754 A new master key MUST be established before the 31-bit SRTCP index 755 cycles back to its original value. Ideally, a rekey should be 756 performed and a new master key put in place well before the SRTCP 757 cycles back to the starting value. 759 The comments on SSRC management in section 9.4 also apply. 761 11. Constraints on AEAD for SRTP and SRTCP 763 In general, any AEAD algorithm can accept inputs with varying 764 lengths, but each algorithm can accept only a limited range of 765 lengths for a specific parameter. In this section, we describe the 766 constraints on the parameter lengths that any AEAD algorithm must 767 support to be used in AEAD-SRTP. Additionally, we specify a complete 768 parameter set for two specific AEAD algorithms, namely AES-GCM and 769 AES-CCM. 771 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the five 772 constraints listed below: 774 PARAMETER Meaning Value 776 A_MAX maximum associated MUST be at least 12 octets. 777 data length 778 N_MIN minimum nonce (IV) MUST be 12 octets. 779 length 780 N_MAX maximum nonce (IV) MUST be 12 octets. 781 length 782 P_MAX maximum plaintext GCM: MUST be <= 2^36-32 octets. 783 length per invocation CCM: MUST be <= 2^24-1 octets. 785 C_MAX maximum ciphertext GCM: MUST be <= 2^36-16 octets. 786 length per invocation CCM: MUST be <= 2^24+15 octets. 788 For GCM the value of P_MAX is based on purely cryptographic 789 considerations. CCM requires the length of the plaintext, measured 790 in octets, must fit in a 24-bit field. Hence P_MAX is 2^24-1.. 792 For sake of clarity we specify two additional parameters: 794 AEAD Authentication Tag Length CCM: MUST be 8, 12, or 16 octets, 795 GCM: MUST be 12 or 16 octets. 796 Maximum number of invocations SRTP: MUST be at most 2^48, 797 for a given instantiation SRTCP: MUST be at most 2^31. 798 Block Counter size CCM: MUST be 24 bits, 799 GCM: MUST be 32 bits. 801 The reader is reminded that the ciphertext is longer than the 802 plaintext by exactly the length of the AEAD authentication tag. 804 12. Key Derivation Functions 806 A Key Derivation Function (KDF) is used to derive all of the required 807 encryption and authentication keys from a secret value shared by the 808 endpoints. Both the AEAD_AES_128_GCM algorithms and the 809 AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key 810 Derivation Function described in [RFC3711]. Both the 811 AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST 812 use the AES_256_CM_PRF Key Derivation Function described in 813 [RFC6188]. 815 13. Summary of Algorithm Characteristics 817 For convenience, much of the information about the use of AES-GCM and 818 AES-CCM algorithms in SRTP is collected in the tables contained in 819 this section. 821 13.1. AES-GCM for SRTP/SRTCP 823 AES-GCM is a family of AEAD algorithms built around the AES block 824 cipher algorithm. AES-GCM uses AES counter mode for encryption and 825 Galois Message Authentication Code (GMAC) for authentication. A 826 detailed description of the AES-GCM family can be found in 827 [RFC5116]. The following members of the AES-GCM family may be used 828 with SRTP/SRTCP: 830 Name Key Size AEAD Tag Size Reference 831 ================================================================ 832 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 833 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 834 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 835 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 837 Table 1: AES-GCM algorithms for SRTP/SRTCP 839 Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM 840 and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication 841 tags), and it MAY support the four other variants shown in table 1. 842 Below we summarize parameters associated with these four GCM 843 algorithms: 845 +--------------------------------+------------------------------+ 846 | Parameter | Value | 847 +--------------------------------+------------------------------+ 848 | Master key length | 128 bits | 849 | Master salt length | 96 bits | 850 | Key Derivation Function | AES_CM_PRF [RFC3711] | 851 | Default key lifetime (SRTP) | 2^48 packets | 852 | Default key lifetime (SRTCP) | 2^31 packets | 853 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_GCM_12 | 854 | AEAD authentication tag length | 96 bits | 855 +--------------------------------+------------------------------+ 857 Table 2: The AEAD_AES_128_GCM_12 Crypto Suite 859 +--------------------------------+------------------------------+ 860 | Parameter | Value | 861 +--------------------------------+------------------------------+ 862 | Master key length | 128 bits | 863 | Master salt length | 96 bits | 864 | Key Derivation Function | AES_CM_PRF [RFC3711] | 865 | Default key lifetime (SRTP) | 2^48 packets | 866 | Default key lifetime (SRTCP) | 2^31 packets | 867 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_GCM | 868 | AEAD authentication tag length | 128 bits | 869 +--------------------------------+------------------------------+ 871 Table 3: The AEAD_AES_128_GCM Crypto Suite 873 +--------------------------------+------------------------------+ 874 | Parameter | Value | 875 +--------------------------------+------------------------------+ 876 | Master key length | 256 bits | 877 | Master salt length | 96 bits | 878 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 879 | Default key lifetime (SRTP) | 2^48 packets | 880 | Default key lifetime (SRTCP) | 2^31 packets | 881 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_GCM_12 | 882 | AEAD authentication tag length | 96 bits | 883 +--------------------------------+------------------------------+ 885 Table 4: The AEAD_AES_256_GCM_12 Crypto Suite 887 +--------------------------------+------------------------------+ 888 | Parameter | Value | 889 +--------------------------------+------------------------------+ 890 | Master key length | 256 bits | 891 | Master salt length | 96 bits | 892 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 893 | Default key lifetime (SRTP) | 2^48 packets | 894 | Default key lifetime (SRTCP) | 2^31 packets | 895 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_GCM | 896 | AEAD authentication tag length | 128 bits | 897 +--------------------------------+------------------------------+ 898 Table 5: The AEAD_AES_256_GCM Crypto Suite 900 13.2. AES-CCM for SRTP/SRTCP 902 AES-CCM is another family of AEAD algorithms built around the AES 903 block cipher algorithm. AES-CCM uses AES counter mode for encryption 904 and AES Cipher Block Chaining Message Authentication Code (CBC-MAC) 905 for authentication. A detailed description of the AES-CCM family can 906 be found in [RFC5116]. Four of the six CCM algorithms used in this 907 document are defined in previous RFCs, while two, AEAD_AES_128_CCM_12 908 and AEAD_AES_256_CCM_12, are defined in section 7 of this document. 910 Any implementation of AES-CCM SRTP/SRTCP MUST support both 911 AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet 912 AEAD authentication tags), and MAY support the other four variants. 914 Name Key Size AEAD Tag Size Reference 915 ================================================================ 916 AEAD_AES_128_CCM 128 bits 16 octets [RFC5116] 917 AEAD_AES_256_CCM 256 bits 16 octets [RFC5116] 918 AEAD_AES_128_CCM_12 128 bits 12 octets see section 7 919 AEAD_AES_256_CCM_12 256 bits 12 octets see section 7 920 AEAD_AES_128_CCM_8 128 bits 8 octets [RFC6655] 921 AEAD_AES_256_CCM_8 256 bits 8 octets [RFC6655] 923 Table 6: AES-CCM algorithms for SRTP/SRTCP 925 In addition to the flag octet used in counter mode encryption, 926 AES-CCM authentications also uses a flag octet that conveys 927 information about the length of the authentication tag, length of the 928 block counter, and presence of additional authenticated data (see 929 section 2.2 of [RFC3610]). For AES-CCM in SRTP/SRTCP, the flag octet 930 has the hex value 5A if an 8-octet AEAD authentication tag is used, 931 6A if a 12-octet AEAD authentication tag is used, and 7A if a 932 16-octet AEAD authentication tag is used. The flag octet is one of 933 the inputs to AES during the counter mode encryption of the 934 plaintext. 936 +--------------------------------+------------------------------+ 937 | Parameter | Value | 938 +--------------------------------+------------------------------+ 939 | Master key length | 128 bits | 940 | Master salt length | 96 bits | 941 | Key Derivation Function | AES_CM_PRF [RFC3711] | 942 | Maximum key lifetime (SRTP) | 2^48 packets | 943 | Maximum key lifetime (SRTCP) | 2^31 packets | 944 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_CCM_8 | 945 | AEAD authentication tag length | 64 bits | 946 +--------------------------------+------------------------------+ 948 Table 7: The AEAD_AES_128_CCM_8 Crypto Suite 950 +--------------------------------+------------------------------+ 951 | Parameter | Value | 952 +--------------------------------+------------------------------+ 953 | Master key length | 128 bits | 954 | Master salt length | 96 bits | 955 | Key Derivation Function | AES_CM_PRF [RFC3711] | 956 | Maximum key lifetime (SRTP) | 2^48 packets | 957 | Maximum key lifetime (SRTCP) | 2^31 packets | 958 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_CCM_12 | 959 | AEAD authentication tag length | 96 bits | 960 +--------------------------------+------------------------------+ 962 Table 8: The AEAD_AES_128_CCM_12 Crypto Suite 964 +--------------------------------+------------------------------+ 965 | Parameter | Value | 966 +--------------------------------+------------------------------+ 967 | Master key length | 128 bits | 968 | Master salt length | 96 bits | 969 | Key Derivation Function | AES_CM_PRF [RFC3711] | 970 | Maximum key lifetime (SRTP) | 2^48 packets | 971 | Maximum key lifetime (SRTCP) | 2^31 packets | 972 | Cipher (for SRTP and SRTCP) | AEAD_AES_128_CCM | 973 | AEAD authentication tag length | 128 bits | 974 +--------------------------------+------------------------------+ 976 Table 9: The AEAD_AES_128_CCM Crypto Suite 978 +--------------------------------+------------------------------+ 979 | Parameter | Value | 980 +--------------------------------+------------------------------+ 981 | Master key length | 256 bits | 982 | Master salt length | 96 bits | 983 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 984 | Maximum key lifetime (SRTP) | 2^48 packets | 985 | Maximum key lifetime (SRTCP) | 2^31 packets | 986 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_CCM_8 | 987 | AEAD authentication tag length | 64 bits | 988 +--------------------------------+------------------------------+ 990 Table 10: The AEAD_AES_256_CCM_8 Crypto Suite 992 +--------------------------------+------------------------------+ 993 | Parameter | Value | 994 +--------------------------------+------------------------------+ 995 | Master key length | 256 bits | 996 | Master salt length | 96 bits | 997 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 998 | Maximum key lifetime (SRTP) | 2^48 packets | 999 | Maximum key lifetime (SRTCP) | 2^31 packets | 1000 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_CCM_12 | 1001 | AEAD authentication tag length | 96 bits | 1002 +--------------------------------+------------------------------+ 1004 Table 11: The AEAD_AES_256_CCM_12 Crypto Suite 1006 +--------------------------------+------------------------------+ 1007 | Parameter | Value | 1008 +--------------------------------+------------------------------+ 1009 | Master key length | 256 bits | 1010 | Master salt length | 96 bits | 1011 | Key Derivation Function | AES_256_CM_PRF [RFC6188] | 1012 | Maximum key lifetime (SRTP) | 2^48 packets | 1013 | Maximum key lifetime (SRTCP) | 2^31 packets | 1014 | Cipher (for SRTP and SRTCP) | AEAD_AES_256_CCM | 1015 | AEAD authentication tag length | 128 bits | 1016 +--------------------------------+------------------------------+ 1018 Table 12: The AEAD_AES_256_CCM Crypto Suite 1020 14. Security Considerations 1022 14.1. Handling of Security Critical Parameters 1024 As with any security process, the implementer must take care to 1025 ensure cryptographically sensitive parameters are properly handled. 1026 Many of these recommendations hold for all SRTP cryptographic 1027 algorithms, but we include them here to emphasize their importance. 1029 - If the master salt is to be kept secret, it MUST be properly 1030 erased when no longer needed. 1031 - The secret master key and all keys derived from it MUST be kept 1032 secret. All keys MUST be properly erased when no longer 1033 needed. 1034 - At the start of each packet, the block counter MUST be reset (to 1035 0 for CCM, to 1 for GCM). The block counter is incremented 1036 after each block key has been produced, but it MUST NOT be 1037 allowed to exceed 2^32-1 for GCM and 2^24-1 for CCM. Note that 1038 even though the block counter is reset at the start of each 1039 packet, IV uniqueness is ensured by the inclusion of 1040 SSRC/ROC/SEQ or SRTCP Index in the IV. (The reader is reminded 1041 that in both GCM and CCM the first block of key produced is 1042 reserved for use in authenticating the packet and is not used to 1043 encrypt plaintext.) 1044 - Each time a rekey occurs, the initial values of the SRTCP index 1045 and the SRTP packet indices MUST be saved in order to prevent IV 1046 reuse. 1047 - Processing MUST cease if the 31-bit SRTCP index or any of the 1048 48-bit packet indices cycle back their initial values . 1049 Processing MUST NOT resume until a new SRTP/SRTCP session has 1050 been established using a new SRTP master key. Ideally, a rekey 1051 should be done well before any of these counters cycle. 1053 14.2. Size of the Authentication Tag 1055 We require that the AEAD authentication tag must be at least 8 1056 octets, significantly reducing the probability of an adversary 1057 successfully introducing fraudulent data. The goal of an 1058 authentication tag is to reduce the probability of a successful 1059 forgery occurring anywhere in the network we are attempting to 1060 defend. There are three relevant factors: how low we wish the 1061 probability of successful forgery to be (prob_success), how many 1062 attempts the adversary can make (N_tries) and the size of the 1063 authentication tag in bits (N_tag_bits). Then 1065 prob_success <= expected number of successes 1066 = N_tries * 2^-N_tag_bits. 1068 When the expected number of successes is much less than one, the 1069 probability of success is well approximated by the expected number of 1070 successes. 1072 Suppose an adversary wishes to introduce a forged or altered packet 1073 into a target network by randomly selecting an authentication value 1074 until by chance they hit a valid authentication tag. The table below 1075 summarizes the relationship between the number of forged packets the 1076 adversary has tried, the size of the authentication tag, and the 1077 probability of a compromise occurring (i.e. at least one of the 1078 attempted forgeries having a valid authentication tag). The reader 1079 is reminded that the forgery attempts can be made over the entire 1080 network, not just a single link, and that frequently changing the key 1081 does not decrease the probability of a compromise occurring. 1083 It should be noted that the cryptographic properties of the GHASH 1084 algorithm used in GCM reduces the effective authentication tag size 1085 (in bits) by the log base 2 of the of blocks of encrypted and/or 1086 authenticated data in a packet. In practice an SRTP payload will be 1087 less than 2^16 bytes, because of the 16-bit IPv4 and UDP length 1088 fields. The exception to this case is IPv6 jumbograms [RFC2675], 1089 which is unlikely to be used for RTP-based multimedia traffic 1090 [RFC3711]. This corresponds to 2^12 blocks of data, so the effective 1091 GCM authentication tag size is reduced by at most 12 bits. 1093 +===========+=============+========================================+ 1094 | Auth. Tag | Eff. Tag | Number of Forgery Attempts | 1095 | Size | Tag Size | Needed to Achieve a Given | 1096 | (bytes) | (bits) | Probability of Success | 1097 |-----------+-------------+------------+-------------+-------------| 1098 | | prob=2^-30 | prob=2^-20 | prob=2^-10 | 1099 |===========+=============+=============+============+=============| 1100 | | 32 (CCM) | 2^2 tries | 2^12 tries | 2^22 tries | 1101 | 4 +-------------+------------+-------------+-------------| 1102 | | 20 (GCM) | 1 try | 1 try | 2^10 tries | 1103 |===========+=============+============+=============+=============| 1104 | | 64 (CCM) | 2^34 tries | 2^44 tries | 2^54 tries | 1105 | 8 +-------------+------------+-------------+-------------| 1106 | | 52 (GCM) | 2^22 tries | 2^32 tries | 2^42 tries | 1107 |===========+=============+============+=============+=============| 1108 | | 96 (CCM) | 2^66 tries | 2^76 tries | 2^86 tries | 1109 | 12 +-------------+------------+-------------+-------------| 1110 | | 84 (GCM) | 2^54 tries | 2^64 tries | 2^74 tries | 1111 |===========+=============+============+=============+=============| 1112 | | 128 (CCM) | 2^86 tries | 2^96 tries | 2^106 tries | 1113 | 16 +-------------+------------+-------------+-------------| 1114 | | 116 (GCM) | 2^98 tries | 2^108 tries | 2^118 tries | 1115 |===========+=============+============+=============+=============| 1117 Table 13: Number of forgery attempts needed to achieve a given 1118 probability of success for various tag sizes. 1120 15. IANA Considerations 1122 15.1. SDES 1124 SDP Security Descriptions [RFC4568] defines SRTP "crypto suites". A 1125 crypto suite corresponds to a particular AEAD algorithm in SRTP. In 1126 order to allow Security Descriptions to signal the use of the 1127 algorithms defined in this document, IANA will register the following 1128 crypto suites into the "SRTP Crypto Suite Registrations" subregistry 1129 of the "Session Description Protocol (SDP) Security Descriptions" 1130 registry. 1132 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 1133 "AEAD_AES_256_GCM" / 1134 "AEAD_AES_128_GCM_12" / 1135 "AEAD_AES_256_GCM_12" / 1136 "AEAD_AES_128_CCM" / 1137 "AEAD_AES_256_CCM" / 1138 "AEAD_AES_128_CCM_8" / 1139 "AEAD_AES_256_CCM_8" / 1140 "AEAD_AES_128_CCM_12" / 1141 "AEAD_AES_256_CCM_12" / 1142 srtp-crypto-suite-ext 1144 15.2. DTLS 1146 DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile". 1147 These also correspond to the use of an AEAD algorithm in SRTP. In 1148 order to allow the use of the algorithms defined in this document in 1149 DTLS-SRTP, we request IANA register the following SRTP Protection 1150 Profiles: 1152 AEAD_AES_128_GCM = {TBD, TBD } 1153 AEAD_AES_256_GCM = {TBD, TBD } 1154 AEAD_AES_128_GCM_12 = {TBD, TBD } 1155 AEAD_AES_256_GCM_12 = {TBD, TBD } 1156 AEAD_AES_128_CCM = {TBD, TBD } 1157 AEAD_AES_256_CCM = {TBD, TBD } 1158 AEAD_AES_128_CCM_8 = {TBD, TBD } 1159 AEAD_AES_256_CCM_8 = {TBD, TBD } 1160 AEAD_AES_128_CCM_12 = {TBD, TBD } 1161 AEAD_AES_256_CCM_12 = {TBD, TBD } 1163 Below we list the SRTP transform parameters for each of these 1164 protection profile. Unless separate parameters for SRTCP and SRTCP 1165 are explicitly listed, these parameters apply to both SRTP and 1166 SRTCP. 1168 AEAD_AES_128_CCM 1169 cipher: AES_128_CCM 1170 cipher_key_length: 128 bits 1171 cipher_salt_length: 96 bits 1172 aead_auth_tag_length: 16 octets 1173 auth_function: NULL 1174 auth_key_length: N/A 1175 auth_tag_length: N/A 1176 maximum lifetime: at most 2^31 SRTCP packets and 1177 at most 2^48 SRTP packets 1179 AEAD_AES_256_CCM 1180 cipher: AES_256_CCM 1181 cipher_key_length: 256 bits 1182 cipher_salt_length: 96 bits 1183 aead_auth_tag_length: 16 octets 1184 auth_function: NULL 1185 auth_key_length: N/A 1186 auth_tag_length: N/A 1187 maximum lifetime: at most 2^31 SRTCP packets and 1188 at most 2^48 SRTP packets 1190 AEAD_AES_128_CCM_8 1191 cipher: AES_128_CCM 1192 cipher_key_length: 128 bits 1193 cipher_salt_length: 96 bits 1194 aead_auth_tag_length: 8 octets 1195 auth_function: NULL 1196 auth_key_length: N/A 1197 auth_tag_length: N/A 1198 maximum lifetime: at most 2^31 SRTCP packets and 1199 at most 2^48 SRTP packets 1201 AEAD_AES_256_CCM_8 1202 cipher: AES_256_CCM 1203 cipher_key_length: 256 bits 1204 cipher_salt_length: 96 bits 1205 aead_auth_tag_length: 8 octets 1206 auth_function: NULL 1207 auth_key_length: N/A 1208 auth_tag_length: N/A 1209 maximum lifetime: at most 2^31 SRTCP packets and 1210 at most 2^48 SRTP packets 1212 AEAD_AES_128_CCM_12 1213 cipher: AES_128_CCM 1214 cipher_key_length: 128 bits 1215 cipher_salt_length: 96 bits 1216 aead_auth_tag_length: 12 octets 1217 auth_function: NULL 1218 auth_key_length: N/A 1219 auth_tag_length: N/A 1220 maximum lifetime: at most 2^31 SRTCP packets and 1221 at most 2^48 SRTP packets 1223 AEAD_AES_256_CCM_12 1224 cipher: AES_256_CCM 1225 cipher_key_length: 256 bits 1226 cipher_salt_length: 96 bits 1227 aead_auth_tag_length: 12 octets 1228 auth_function: NULL 1229 auth_key_length: N/A 1230 auth_tag_length: N/A 1231 maximum lifetime: at most 2^31 SRTCP packets and 1232 at most 2^48 SRTP packets 1234 AEAD_AES_128_GCM 1235 cipher: AES_128_GCM 1236 cipher_key_length: 128 bits 1237 cipher_salt_length: 96 bits 1238 aead_auth_tag_length: 16 octets 1239 auth_function: NULL 1240 auth_key_length: N/A 1241 auth_tag_length: N/A 1242 maximum lifetime: at most 2^31 SRTCP packets and 1243 at most 2^48 SRTP packets 1245 AEAD_AES_256_GCM 1246 cipher: AES_256_GCM 1247 cipher_key_length: 256 bits 1248 cipher_salt_length: 96 bits 1249 aead_auth_tag_length: 16 octets 1250 auth_function: NULL 1251 auth_key_length: N/A 1252 auth_tag_length: N/A 1253 maximum lifetime: at most 2^31 SRTCP packets and 1254 at most 2^48 SRTP packets 1256 AEAD_AES_128_GCM_12 1257 cipher: AES_128_GCM 1258 cipher_key_length: 128 bits 1259 cipher_salt_length: 96 bits 1260 aead_auth_tag_length: 12 octets 1261 auth_function: NULL 1262 auth_key_length: N/A 1263 auth_tag_length: N/A 1264 maximum lifetime: at most 2^31 SRTCP packets and 1265 at most 2^48 SRTP packets 1267 AEAD_AES_256_GCM_12 1268 cipher: AES_256_GCM 1269 cipher_key_length: 256 bits 1270 cipher_salt_length: 96 bits 1271 aead_auth_tag_length: 12 octets 1272 auth_function: NULL 1273 auth_key_length: N/A 1274 auth_tag_length: N/A 1275 maximum lifetime: at most 2^31 SRTCP packets and 1276 at most 2^48 SRTP packets 1278 Note that these SRTP Protection Profiles do not specify an 1279 auth_function, auth_key_length, or auth_tag_length because all of 1280 these profiles use AEAD algorithms, and thus do not use a separate 1281 auth_function, auth_key, or auth_tag. The term aead_auth_tag_length 1282 is used to emphasize that this refers to the authentication tag 1283 provided by the AEAD algorithm and that this tag is not located in 1284 the authentication tag field provided by SRTP/SRTCP. 1286 15.3. MIKEY 1288 In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], 1289 IANA maintains several subregitries under "Multimedia Internet KEYing 1290 (MIKEY) Payload Name Spaces". This document requires additions to 1291 two of the MIKEY subregistries. 1293 In the "MIKEY Security Protocol Parameters" subregistry we request 1294 the following addition: 1296 Type | Meaning | Possible values 1297 ---------------------------------------------------------------- 1298 TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) 1300 This list is, of course, intended for use with CM and GCM. It is 1301 conceivable that new AEAD algorithms introduced at some point in the 1302 future may require a different set of Authentication tag lengths. 1304 In the "Encryption Algorithm" subregistry (derived from Table 1305 6.10.1.b of [RFC3830]) we request the following additions: 1307 SRTP encr | Value | Default Session | Default Auth. 1308 Algorithm | | Encr. Key Length | Tag Length 1309 ----------------------------------------------------------- 1310 AES-CCM | TBD | 16 octets | 16 octets 1311 AES-GCM | TBD | 16 octets | 16 octets 1313 The SRTP encryption algorithm, session encryption key length, and 1314 AEAD authentication tag values received from MIKEY fully determine 1315 the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is 1316 described in section 16. 1318 15.4. AEAD registry 1320 We request that IANA make the following additions to the IANA 1321 "Authenticated Encryption with Associated Data (AEAD) Parameters" 1322 page's registry for "AEAD Algorithms": 1324 AEAD_AES_128_CCM_12 = TBD 1325 AEAD_AES_256_CCM_12 = TBD 1327 16. Parameters for use with MIKEY 1329 MIKEY specifies the algorithm family separately from the key length 1330 (which is specified by the Session Encryption key length) and the 1331 authentication tag length (specified by AEAD Auth. tag length). 1333 +------------+-------------+-------------+ 1334 | Encryption | Encryption | AEAD Auth. | 1335 | Algorithm | Key Length | Tag Length | 1336 +============+=============+=============+ 1337 AEAD_AES_128_GCM | AES-GCM | 16 octets | 16 octets | 1338 +------------+-------------+-------------+ 1339 AEAD_AES_128_CCM | AES-CCM | 16 octets | 16 octets | 1340 +------------+-------------+-------------+ 1341 AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets | 1342 +------------+-------------+-------------+ 1343 AEAD_AES_128_CCM_12 | AES-CCM | 16 octets | 12 octets | 1344 +------------+-------------+-------------+ 1345 AEAD_AES_128_CCM_8 | AES-CCM | 16 octets | 8 octets | 1346 +------------+-------------+-------------+ 1347 AEAD_AES_256_GCM | AES-GCM | 32 octets | 16 octets | 1348 +------------+-------------+-------------+ 1349 AEAD_AES_256_CCM | AES-CCM | 32 octets | 16 octets | 1350 +------------+-------------+-------------+ 1351 AEAD_AES_256_GCM_12 | AES-GCM | 32 octets | 12 octets | 1352 +------------+-------------+-------------+ 1353 AEAD_AES_256_CCM_12 | AES-CCM | 32 octets | 12 octets | 1354 +------------+-------------+-------------+ 1355 AEAD_AES_256_CCM_8 | AES-CCM | 32 octets | 8 octets | 1356 +============+=============+=============+ 1358 Table 14: Mapping MIKEY parameters to AEAD algorithm 1360 Section 12 in this document restricts the choice of Key Derivation 1361 Function for AEAD algorithms. To enforce this restriction in MIKEY, 1362 we require that the SRTP PRF has value AES-CM whenever an AEAD 1363 algorithm is used. Note that, according to Section 6.10.1 in 1364 [RFC3830], the input key length of the Key Derivation Function (i.e. 1365 the SRTP master key length) is always equal to the session encryption 1366 key length. This means, for example, that AEAD_AES_256_GCM will use 1367 AES_256_CM_PRF as the Key Derivation Function. 1369 17. Acknowledgements 1371 The authors would like to thank Michael Peck, Michael Torla, Qin Wu, 1372 Magnus Westerland, Oscar Ohllson, Woo-Hwan Kim, John Mattsson, 1373 Richard Barnes, John Mattisson, Morris Dworkin and many other 1374 reviewers who provided valuable comments on earlier drafts of this 1375 document. 1377 18. References 1379 18.1. Normative References 1381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1382 Requirement Levels", BCP 14, RFC 2119, March 1997. 1384 [RFC3550] Casner, S., Frederick, R., and V. Jacobson, "RTP: A 1385 Transport Protocol for Real-Time Applications", RFC 3550, 1386 July 2003. 1388 [RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with 1389 CBC-MAC (CCM)", RFC 3610, March 2004. 1391 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 1392 K. Norrman, "The Secure Real-time Transport Protocol 1393 (SRTP)", RFC 3711, September 2003. 1395 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and 1396 Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1397 August 2004. 1399 [RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session 1400 Description Protocol (SDP): Security Descriptions for 1401 Media Streams", RFC 4568, July 2006. 1403 [RFC5116] McGrew, D., "An Interface and Algorithms for 1404 Authenticated Encryption with Associated Data", RFC 5116, 1405 January 2008. 1407 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 1408 Algorithms with the Encrypted Payload of the Internet Key 1409 Exchange version 2 (IKEv2) Protocol", RFC 5282, 1410 August 2008. 1412 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1413 Security (DTLS) Extension to Establish Keys for the Secure 1414 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1416 [RFC6188] D. McGrew, "The Use of AES-192 and AES-256 in Secure 1417 RTP", RFC 6188, March 2011. 1419 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1420 Transport Layer Security (TLS)", RFC 6655, July 2012. 1422 [RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure 1423 Real-Time Transport Protocol (SRTP)", January 2013. 1425 , January 2013. 1427 [RFC6904] J. Lennox, "Encryption of Header Extensions in the Secure 1428 Real-Time Transport Protocol (SRTP)", January 2013. 1430 18.2. Informative References 1432 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 1433 Relations among notions and analysis of the generic 1434 composition paradigm", Proceedings of ASIACRYPT 2000, 1435 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 1436 www-cse.ucsd.edu/users/mihir/papers/oem.html. 1438 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 1439 Recommendation for Block Cipher Modes of Operation: 1440 Galois/Counter Mode (GCM) and GMAC.", U.S. National 1441 Institute of Standards and Technology http:// 1442 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 1444 [R02] Rogaway, P., "Authenticated encryption with Associated- 1445 Data", ACM Conference on Computer and Communication 1446 Security (CCS'02), pp. 98-107, ACM Press, 1447 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 1449 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1450 Jacobson, "RTP: A Transport Protocol for Real-Time 1451 Applications", STD 64, RFC 3550, July 2003. 1453 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1454 Transform Carrying Roll-Over Counter for the Secure Real- 1455 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1457 Author's Address 1459 David A. McGrew 1460 Cisco Systems, Inc. 1461 510 McCarthy Blvd. 1462 Milpitas, CA 95035 1463 US 1464 Phone: (408) 525 8651 1465 Email: mcgrew@cisco.com 1466 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1468 Kevin M. Igoe 1469 NSA/CSS Commercial Solutions Center 1470 National Security Agency 1471 EMail: kmigoe@nsa.gov 1473 Acknowledgement 1475 Funding for the RFC Editor function is provided by the IETF 1476 Administrative Support Activity (IASA).