idnits 2.17.1 draft-ietf-avtcore-srtp-aes-gcm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 22, 2013) is 4074 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: 'RFCXXX' is mentioned on line 498, but not defined == Missing Reference: 'RFC 3610' is mentioned on line 786, but not defined == Missing Reference: 'RFC 4568' is mentioned on line 877, but not defined == Unused Reference: 'CCM' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'RFC4568' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC6188' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'RFCXXXX' is defined on line 1184, but no explicit reference was found in the text == Unused Reference: 'BOYD' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: 'CMAC' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: 'EEM04' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: 'GR05' is defined on line 1209, but no explicit reference was found in the text == Unused Reference: 'J02' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'MV04' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1256, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' ** Downref: Normative reference to an Informational RFC: RFC 3610 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX' Summary: 3 errors (**), 0 flaws (~~), 22 warnings (==), 4 comments (--). 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: August 26, 2013 National Security Agency 5 February 22, 2013 7 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 8 draft-ietf-avtcore-srtp-aes-gcm-05 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 August 26, 2013. 27 Copyright Notice 29 Copyright (c) 2013 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.....................................................4 51 2. Conventions Used In This Document................................4 52 3. Overview of the SRTP/SRTCP Security Architecture.................5 53 4. Terminology......................................................5 54 5. Generic AEAD Processing..........................................6 55 5.1. Types of Input Data.........................................6 56 5.2. AEAD Invocation Inputs and Outputs..........................6 57 5.2.1. Encrypt Mode...........................................6 58 5.2.2. Decrypt Mode...........................................7 59 5.3. Handling of AEAD Authentication.............................7 60 6. Counter Mode Encryption..........................................8 61 7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................9 62 8. Unneeded SRTP/SRTCP Fields.......................................9 63 8.1. SRTP/SRTCP Authentication Field.............................9 64 8.2. RTP Padding................................................10 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................................12 70 10. AES-GCM/CCM Processing of SRTCP Compound Packets...............13 71 10.1. SRTCP IV formation for AES-GCM and AES-CCM................13 72 10.2. Data Types in Encrypted SRTCP Compound Packets............13 73 10.3. Data Types in Unencrypted SRTCP Compound Packets..........14 74 10.4. Prevention of SRTCP IV Reuse..............................15 75 11. Constraints on AEAD for SRTP and SRTCP.........................16 76 11.1. Generic AEAD Parameter Constraints........................16 77 11.2. AES-GCM for SRTP/SRTCP....................................17 78 11.3. AES-CCM for SRTP/SRTCP....................................17 79 12. Key Derivation Functions.......................................18 80 13. Security Considerations........................................18 81 13.1. Handling of Security Critical Parameters..................18 82 13.2. Size of the Authentication Tag............................18 83 14. IANA Considerations............................................19 84 14.1. SDES......................................................19 85 14.2. DTLS......................................................20 86 14.3. MIKEY.....................................................23 87 14.4. AEAD registry.............................................23 88 15. Parameters for use with MIKEY..................................23 89 16. Acknowledgements...............................................24 90 17. References.....................................................25 91 17.1. Normative References......................................25 92 17.2. Informative References....................................27 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 The Galois/Counter Mode of operation (GCM) and the Counter with 123 Cipher Block Chaining-Message Authentication Code mode of operation 124 (CCM) are both AEAD modes of operation for block ciphers. Both use 125 counter mode to encrypt the data, an operation that can be 126 efficiently pipelined. Further, GCM authentication uses operations 127 that are particularly well suited to efficient implementation in 128 hardware, making it especially appealing for high-speed 129 implementations, or for implementations in an efficient and compact 130 circuit. CCM is well suited for use in compact software 131 implementations. This specification uses GCM and CCM with both 132 AES-128 and AES-256. 134 In summary, this document defines how to use AEAD algorithms, 135 particularly AES-GCM and AES-CCM, to provide confidentiality and 136 message authentication within SRTP and SRTCP packets. 138 2. Conventions Used In This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Overview of the SRTP/SRTCP Security Architecture 146 SRTP/SRTCP security is based upon the following principles: 148 a) Both privacy and authentication are based upon the use of 149 symmetric algorithms. An AEAD algorithm such as AES-CCM or 150 AES-GCM combines privacy and authentication into a single 151 process. 153 b) A secret master key is shared by all participating endpoints, 154 both those originating SRTP/SRTCP packets and those receiving 155 these packets. Any given master key MAY be used 156 simultaneously by several endpoints to originate SRTP/SRTCP 157 packets (as well one or more endpoints using this master key 158 to process inbound data). 160 c) A Key Derivation Function is applied to the shared master key 161 value to form separate encryption keys, authentication keys 162 and salting keys for SRTP and for SRTCP (a total of six 163 keys). This process is described in sections 4.3.1 and 4.3.3 164 of [RFC3711]. Since AEAD algorithms such as AES-CCM and 165 AES-GCM combine encryption and authentication into a single 166 process, AEAD algorithms do not make use of the 167 authentication keys. The master key MUST be at least as 168 large as the encryption key derived from it. 170 d) Each time an instantiation of AES-GCM or AES-CCM is invoked 171 to encrypt and authenticate an SRTP or SRTCP data packet a 172 new IV is used. SRTP combines the 4-octet synchronization 173 source (SSRC) identifier, the 4-octet rollover counter (ROC), 174 and the 2-octet sequence number(SEQ) with the 12-octet 175 encryption salt to form a 12-octet IV (see section 9.1). 176 SRTCP combines the SSRC and 31-bit SRTCP index with the 177 encryption salt to form a 12-octet IV (see section 10.1). 179 4. Terminology 181 The following terms have very specific meanings in the context of 182 this RFC: 184 Crypto Context: For the purposes of this document, a crypto 185 context is the outcome of any process which 186 results in authentication of each endpoint in the 187 SRTP session and possession by each endpoint of a 188 shared secret master key. Various encryption 189 keys, authentication keys and salts are derived 190 from the master key. Aside from making 191 modifications to IANA registries to allow AES-GCM 192 and AES-CCM to work with SDES, DTLS and MIKEY, 193 the details of how the master key is established 194 are outside the scope of this document. 195 Similarly any mechanism for rekeying an existing 196 Cipher Context is outside the scope of the 197 document. 199 Instantiation: In AEAD, an instantiation is an (Encryption_key, 200 salt) pair together with all of the data 201 structures (for example, counters) needed for it 202 to function properly. In SRTP/SRTCP, each 203 endpoint will need two instantiations of the AEAD 204 algorithm for each master key in its possession, 205 one instantiation for SRTP traffic and one 206 instantiation for SRTCP traffic. 208 Invocation: SRTP/SRTCP data streams are broken into packets. 209 Each packet is processed by a single invocation 210 of the appropriate instantiation of the AEAD 211 algorithm. 213 In many applications, each endpoint will have one master key for 214 processing outbound data but may have one or more separate master 215 keys for processing inbound data. 217 5. Generic AEAD Processing 219 5.1. Types of Input Data 221 Associated Data: This is data that is to be authenticated 222 but not encrypted. 224 Plaintext: Data that is to be both encrypted and 225 authenticated. 227 Raw Data: Data that is to be neither encrypted nor 228 authenticated. 230 Which portions of SRTP/SRTCP packets that are to be treated as 231 associated data, which are to be treated as plaintext, and which are 232 to be treated as raw data are covered in sections 9.2, 10.2 and 233 10.3. 235 5.2. AEAD Invocation Inputs and Outputs 237 5.2.1. Encrypt Mode 239 Inputs: 240 Encryption_key Octet string, either 16 or 32 241 octets long 242 Initialization_Vector Octet string, 12 octets long 243 Associated_Data Bit string of variable length 244 Plaintext Bit string of variable length 245 Tag_Size_Flag (CCM only*) One Octet 247 Outputs 248 Ciphertext Bit string, length = 249 length(Plaintext)+tag_length 251 (*) For GCM, the algorithm choice determines the tag size. 253 AES-CCM uses a Tag_Size_Flag that has the hex value 5A if an 8-octet 254 authentication tag is used, 6A if a 12-octet authentication tag is 255 used, and 7A if a 16-octet authentication tag is used. This flag 256 refers to the size of the intrinsic authentication tag provided by 257 the AEAD algorithm. 259 5.2.2. Decrypt Mode 261 Inputs: 262 Encryption_key Octet string, either 16 or 32 263 Octets long 264 Initialization_Vector Octet string, 12 octets long 265 Associated_Data Octet string of variable length 266 Ciphertext Octet string of variable length 267 Tag_Size_Flag (CCM only*) One octet 269 Outputs 270 Plaintext Bit string, length = 271 length(Ciphertext)-tag_length 272 Validity_Flag Boolean, TRUE if valid, 273 FALSE otherwise 275 (*) For GCM, the algorithm choice determines the tag size. 277 The Tag_Size_Flag, used in AES-CCM authentication, has the hex value 278 5A if an 8-octet authentication tag is used, 6A if a 12-octet 279 authentication tag is used, and 7A if a 16-octet authentication tag 280 is used. This flag refers to the size of the intrinsic 281 authentication tag provided by the AEAD algorithm. 283 5.3. Handling of AEAD Authentication 285 AEAD requires that all incoming packets MUST pass AEAD authentication 286 before any other action takes place. Plaintext and associated data 287 MUST NOT be released until the AEAD authentication tag has been 288 validated. Further, when GCM is being used, the ciphertext MUST NOT 289 be decrypted until the AEAD tag has been validated. 291 Should the AEAD tag prove to be invalid, the packet in question is to 292 be discarded and a Validation Error flag raised. Local policy 293 determines how this flag is to be handled and is outside the scope of 294 this document. 296 6. Counter Mode Encryption 298 In both GCM and CCM, each outbound packet uses a 12-octet IV and an 299 encryption key to form two outputs, a 16-octet first_key_block which 300 is used in forming the authentication tag and a keystream of octets 301 which is XORed to the plaintext to form cipher. 303 When GCM is used, the concatenation of a 12-octet IV (see sections 304 9.1 and 10.1)with a 4-octet block counter forms the input to AES. 305 This is used to build a key_stream as follows: 307 def GCM_keystream( Plaintext, IV, Encryption_key ): 308 assert len(plaintext) <= (2**36) - 32 309 key_stream = "" 310 block_counter = 1 311 first_key_block = AES_ENC( data=IV||block_counter, 312 key=Encryption_key ) 313 while len(key_stream) < len(Plaintext): 314 block_counter = block_counter + 1 315 key_block = AES_ENC( data=IV||block_counter, 316 key=Encryption_key ) 317 key_stream = key_stream || key_block 318 key_stream = truncate( key_stream, len(Plaintext) ) 319 return (first_key_block, key_stream ) 321 In AES-CCM counter mode encryption, the AES data input consists of 322 the concatenation of a 1-octet flag,, a 12-octet IV, and a 3-octet 323 block counter. Note that in this application the flag octet will 324 always have the value 0x02 (see section 2.3 of [RFC3610]). A 325 (first_key_block, keystream) pair is formed as follows: 327 def CCM_keystream( Plaintext, IV, Encryption_key ): 328 assert len(Plaintext) <= (2**28)-16 329 key_stream = "" 330 block_counter = 0 331 first_key_block = AES_ENC( data=0x02||IV||block_counter, 332 key=Encryption_key ) 333 while len(key_stream)(+) 418 +--+--+--+--+--+--+--+--+--+--+--+--+ | 419 | 420 +--+--+--+--+--+--+--+--+--+--+--+--+ | 421 | Initialization Vector |<--+ 422 +--+--+--+--+--+--+--+--+--+--+--+--+ 424 Figure 1: AES-GCM and AES-CCM SRTP 425 Initialization Vector formation. 427 9.2. Data Types in SRTP Packets 429 All SRTP packets MUST be both authenticated and encrypted. The data 430 fields within the SRTP packets are broken into Associated Data, 431 Plaintext and Raw Data as follows (see figure 2): 433 Associated Data: The version (2 bits), padding flag (1 bit), 434 extension flag (1 bit), CSRC count (4 bits), 435 sequence number (16 bits), timestamp (32 bits), 436 SSRC (32 bits), optional contributing source 437 identifiers (CSRCs, 32 bits each), and optional 438 RTP extension (variable length). 440 Plaintext: The RTP payload (variable length), RTP padding 441 (if used, variable length), and RTP pad count ( 442 if used, 1 octet). 444 Raw Data: The optional 32-bit SRTP MKI and the 32-bit SRTP 445 authentication tag (whose use is NOT 446 RECOMMENDED). 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 A |V=2|P|X| CC |M| Packet Type | sequence number | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 A | timestamp | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 A | synchronization source (SSRC) identifier | 456 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 457 A | contributing source (CSRC) identifiers (optional) | 458 A | .... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 A | RTP extension (OPTIONAL) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 P | payload ... | 463 P | +-------------------------------+ 464 P | | RTP padding | RTP pad count | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 R : SRTP MKI (optional) : 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 R : authentication tag (NOT RECOMMENDED) : 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 P = Plaintext (to be encrypted and authenticated) 472 A = Associated Data (to be authenticated only) 473 R = neither encrypted nor authenticated 475 Note: The RTP padding and RTP padding count fields are optional 476 and are not recommended 478 Figure 2: AEAD inputs from an SRTP packet 480 Since the AEAD cipher is larger than the plaintext by exactly the 481 length of the AEAD authentication tag, the corresponding SRTP 482 encrypted packet replaces the plaintext field by a slightly larger 483 field containing the cipher. Even if the plaintext field is empty, 484 AEAD encryption must still be performed, with the resulting cipher 485 consisting solely of the authentication tag. This tag is to be 486 placed immediately before the optional SRTP MKI and SRTP 487 authentication tag fields. 489 9.3. Handling Header Extensions 491 RTP header extensions were first defined in RFC 3550. RFC XXXX 492 [RFCXXX] describes how these header extensions are to be encrypted in 493 SRTP. 495 When RFC XXXX is in use, a separate keystream is generated to encrypt 496 selected RTP header extension elements. For the AEAD_AES_128_GCM and 497 the AEAD_AES_128_CCM algorithms, this keystream MUST be generated in 498 the manner defined in [RFCXXX] using the AES_128_CM transform. For 499 the AEAD_AES_256_GCM and the AEAD_AES_256_CCM algorithms, the 500 keystream MUST be generated in the manner defined for the AES_256_CM 501 transform. The originator must perform any required header extension 502 encryption before the AEAD algorithm is invoked. 504 As with the other fields contained within the RTP header, both 505 encrypted and unencrypted header extensions are to be treated by the 506 AEAD algorithm as Additional Authenticated Data (AAD). Thus the AEAD 507 algorithm does not provide any additional privacy for the header 508 extensions, but does provide integrity and authentication. 510 9.4. Prevention of SRTP IV Reuse 512 In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC) 513 triple is never used twice with the same master key. There are two 514 phases to this issue. 516 Counter Management: A rekey MUST be performed to establish a new 517 master key before the (ROC,SEQ) pair cycles 518 back to its original value. 520 SSRC Management: For a given master key, the set of all SSRC 521 values used with that master key must be 522 partitioned into disjoint pools, one pool for 523 each endpoint using that master key to 524 originate outbound data. Each such originating 525 endpoint MUST only issue SSRC values from the 526 pool it has been assigned. Further, each 527 originating endpoint MUST maintain a history of 528 outbound SSRC identifiers that it has issued 529 within the lifetime of the current master key, 530 and when a new synchronization source requests 531 an SSRC identifier it MUST NOT be given an 532 identifier that has been previously issued. A 533 rekey MUST be performed before any of the 534 originating endpoints using that master key 535 exhausts its pool of SSRC values. 537 10. AES-GCM/CCM Processing of SRTCP Compound Packets 539 All SRTCP compound packets MUST be authenticated, but unlike SRTP, 540 SRTCP packet encryption is optional. A sender can select which 541 packets to encrypt, and indicates this choice with a 1-bit encryption 542 flag (located just before the 31-bit SRTCP index) 544 10.1. SRTCP IV formation for AES-GCM and AES-CCM 546 The 12 octet initialization vector used by both AES-GCM and AES-CCM 547 SRTCP is formed by first concatenating 2-octets of zeroes, the 548 4-octet Synchronization Source identifier (SSRC), 2-octets of zeroes, 549 a single zero bit, and the 31-bit SRTCP Index. The resulting 550 12-octet value is then XORed to the 12-octet salt to form the 551 12-octet IV. 553 0 1 2 3 4 5 6 7 8 9 10 11 554 +--+--+--+--+--+--+--+--+--+--+--+--+ 555 |00|00| SSRC |00|00|0+SRTCP Idx|---+ 556 +--+--+--+--+--+--+--+--+--+--+--+--+ | 557 | 558 +--+--+--+--+--+--+--+--+--+--+--+--+ | 559 | Encryption Salt |->(+) 560 +--+--+--+--+--+--+--+--+--+--+--+--+ | 561 | 562 +--+--+--+--+--+--+--+--+--+--+--+--+ | 563 | Initialization Vector |<--+ 564 +--+--+--+--+--+--+--+--+--+--+--+--+ 566 Figure 3: SRTCP Initialization Vector formation 568 10.2. Data Types in Encrypted SRTCP Compound Packets 570 When the encryption flag is set to 1, the SRTCP packet is broken into 571 plaintext, associated data, and raw (untouched) data as listed below 572 (see figure 4): 574 Associated Data: The packet version (2 bits), padding flag (1 575 bit), reception report count (5 bits), packet 576 type (8 bits), length (2 octets), SSRC (4 577 octets), encryption flag (1 bit) and SRTCP index 578 (31 bits). 580 Raw Data: The 32-bit optional SRTCP MKI index and 32-bit 581 SRTCP authentication tag (whose use is NOT 582 RECOMMENDED). 584 Plaintext: All other data. 586 Note that the plaintext comes in one contiguous field. Since the 587 AEAD cipher is larger than the plaintext by exactly the length of the 588 AEAD authentication tag, the corresponding SRTCP encrypted packet 589 replaces the plaintext field with a slightly larger field containing 590 the cipher. Even if the plaintext field is empty, AEAD encryption 591 must still be performed, with the resulting cipher consisting solely 592 of the authentication tag. This tag is to be placed immediately 593 before the encryption flag and SRTCP index. 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 A |V=2|P| RC | Packet Type | length | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 A | synchronization source (SSRC) of Sender | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 P | sender info | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 P | report block 1 | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 P | report block 2 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 P | ... | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 P |V=2|P| SC | Packet Type | length | 611 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 612 P | SSRC/CSRC_1 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 P | SDES items | 615 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 616 P | ... | 617 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 618 A |1| SRTCP index | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 R | SRTCP MKI (optional) index | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 R : authentication tag (NOT RECOMMENDED) : 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 P = Plaintext (to be encrypted and authenticated) 626 A = Associated Data (to be authenticated only) 627 R = neither encrypted nor authenticated 629 Figure 4: AEAD SRTCP inputs when encryption flag = 1. 631 10.3. Data Types in Unencrypted SRTCP Compound Packets 633 When the encryption flag is set to 0, the SRTCP compound packet is 634 broken into plaintext, associated data, and raw (untouched) data as 635 follows (see figure 5): 637 Plaintext: None. 639 Raw Data: The 32-bit optional SRTCP MKI index and 32-bit 640 SRTCP authentication tag (whose use is NOT 641 RECOMMENDED). 643 Associated Data: All other data. 645 Even though there is no plaintext in this RTCP packet, AEAD 646 encryption returns a cipher field which is precisely the length of 647 the AEAD authentication tag. This cipher is to be placed before the 648 Encryption flag and the SRTCP index in the authenticated SRTCP 649 packet. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 A |V=2|P| RC | Packet Type | length | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 A | synchronization source (SSRC) of Sender | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 A | sender info | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 A | report block 1 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 A | report block 2 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 A | ... | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 A |V=2|P| SC | Packet Type | length | 667 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 668 A | SSRC/CSRC_1 | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 A | SDES items | 671 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 672 A | ... | 673 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 674 A |0| SRTCP index | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 R | SRTCP MKI (optional)index | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 R : authentication tag (NOT RECOMMENDED) : 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 A = Associated Data (to be authenticated only) 682 R = neither encrypted nor authenticated 684 Figure 5: AEAD SRTCP inputs when encryption flag = 0 686 10.4. Prevention of SRTCP IV Reuse 687 A new master key MUST be established before the 31-bit SRTCP index 688 cycles back to its original value. Ideally, a rekey performed should 689 be performed and a new master key put in place well before the SRTCP 690 index overflows. 692 The comments on SSRC management in section 9.3 also apply. 694 11. Constraints on AEAD for SRTP and SRTCP 696 In general, any AEAD algorithm can accept inputs with varying 697 lengths, but each algorithm can accept only a limited range of 698 lengths for a specific parameter. In this section, we describe the 699 constraints on the parameter lengths that any AEAD algorithm must 700 support to be used in AEAD-SRTP. Additionally, we specify a complete 701 parameter set for two specific AEAD algorithms, namely AES-GCM and 702 AES-CCM. 704 11.1. Generic AEAD Parameter Constraints 706 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three 707 constraints listed below: 709 PARAMETER Meaning Value 711 A_MAX maximum additional MUST be at least 12 octets. 712 authenticated data 713 length 714 N_MIN minimum nonce (IV) MUST be 12 octets. 715 length 716 N_MAX maximum nonce (IV) MUST be 12 octets. 717 length 718 C_MAX maximum ciphertext GCM: MUST be at most 2^36-16 octets. 719 length per invocation CCM: MUST be at most 2^24+16 octets 721 The values for C_MAX are based on purely cryptographic 722 considerations. 724 For sake of clarity we specify two additional parameters: 726 AEAD Authentication Tag Length MUST be either 8, 12, or 16 727 octets 728 Maximum number of invocations MUST be at most 2^48 for SRTP 729 for a given instantiation MUST be at most 2^31 for SRTCP 730 Block Counter size MUST be 24 bits for CCM, 731 MUST be 32 bits for GCM 733 The reader is reminded that the ciphertext is longer than the 734 plaintext by exactly the length of the AEAD authentication tag. 736 11.2. AES-GCM for SRTP/SRTCP 738 AES-GCM is a family of AEAD algorithms built around the AES block 739 cipher algorithm. AES-GCM uses AES counter mode for encryption and 740 Galois Message Authentication Code (GMAC) for authentication. A 741 detailed description of the AES-GCM family can be found in 742 [RFC5116]. The following members of the AES-GCM family may be used 743 with SRTP/SRTCP: 745 Table 1: AES-GCM algorithms for SRTP/SRTCP 746 Name Key Size AEAD Tag Size Reference 747 ================================================================ 748 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 749 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 750 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 751 AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] 752 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 753 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 755 Any implementation of AES-GCM SRTP SHOULD support both 756 AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8, and it MAY support the 757 four other variants shown in table 1. 759 11.3. AES-CCM for SRTP/SRTCP 761 AES-CCM is another family of AEAD algorithms built around the AES 762 block cipher algorithm. AES-CCM uses AES counter mode for encryption 763 and AES Cipher Block Chaining Message Authentication Code (CBC MAC) 764 for authentication. A detailed description of the AES-CCM family can 765 be found in [RFC5116]. Four of the six CCM algorithms used in this 766 document are defined in previous RFCs, while two, AEAD_AES_128_CCM_12 767 and AEAD_AES_256_CCM_12, are defined in section 7 of this document. 769 Table 2: AES-CCM algorithms for SRTP/SRTCP 770 Name Key Size AEAD Tag Size Reference 771 ================================================================ 772 AEAD_AES_128_CCM 128 bits 16 octets [RFC5116] 773 AEAD_AES_256_CCM 256 bits 16 octets [RFC5116] 774 AEAD_AES_128_CCM_12 128 bits 12 octets see section 7 775 AEAD_AES_256_CCM_12 256 bits 12 octets see section 7 776 AEAD_AES_128_CCM_8 128 bits 8 octets [RFC6655] 777 AEAD_AES_256_CCM_8 256 bits 8 octets [RFC6655] 779 Any implementation of AES-CCM SRTP/SRTCP SHOULD support both 780 AEAD_AES_128_CCM and AEAD_AES_256_CCM. 782 In addition to the flag octet used in counter mode encryption, 783 AES-CCM authentications also uses a flag octet that conveys 784 information about the length of the authentication tag, length of the 785 block counter, and presence of additional authenticated data (see 786 section 2.2 of [RFC 3610]). For AES-CCM in SRTP/SRTCP, the flag 787 octet has the hex value 5A if an 8-octet AEAD authentication tag is 788 used, 6A if a 12-octet AEAD authentication tag is used, and 7A if a 789 16-octet AEAD authentication tag is used. The flag octet is one of 790 the inputs to AES during the counter mode encryption of the 791 plaintext. 793 12. Key Derivation Functions 795 A Key Derivation Function (KDF) is used to derive all of the required 796 encryption and authentication keys from a secret value shared by the 797 endpoints. Both the AEAD_AES_128_GCM algorithms and the 798 AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key 799 Derivation Function described in [RFC3711]. Both the 800 AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST 801 use the AES_256_CM_PRF Key Derivation Function described in [RFC 802 6188]. 804 13. Security Considerations 806 13.1. Handling of Security Critical Parameters 808 As with any security process, the implementer must take care to 809 ensure cryptographically sensitive parameters are properly handled. 810 Many of these recommendations hold for all SRTP cryptographic 811 algorithms, but we include them here to emphasize their importance. 813 - If the master salt is to be kept secret, it MUST be properly 814 erased when no longer needed. 815 - The secret master key and all keys derived from it MUST be kept 816 secret. All keys MUST be properly erased when no longer 817 needed. 818 - At the start of each packet, the block counter MUST be reset (to 819 0 for CCM, to 1 for GCM). The block counter is incremented 820 after each block key has been produced, but it MUST NOT be 821 allowed to exceed 2^32 for GCM and 2^24 for CCM. 822 - Each time a rekey occurs, the initial values of the SRTCP index 823 and the values of all the SEQ counters MUST be saved. 824 - Processing MUST cease if the 48-bit Packet Counter or the 31-bit 825 SRTCP index cycles back to its initial value. Processing MUST 826 NOT resume until a new SRTP/SRTCP session has been established 827 using a new SRTP master key. Ideally, a rekey should be done 828 well before either of these counters cycle. 830 13.2. Size of the Authentication Tag 832 We require that the AEAD authentication tag must be at least 8 833 octets, significantly reducing the probability of an adversary 834 successfully introducing fraudulent data. The goal of an 835 authentication tag is to minimize the probability of a successful 836 forgery occurring anywhere in the network we are attempting to 837 defend. There are three relevant factors: how low we wish the 838 probability of successful forgery to be (prob_success), how many 839 attempts the adversary can make (N_tries) and the size of the 840 authentication tag in bits (N_tag_bits). Then 842 prob_success < expected number of successes 843 = N_tries * 2^-N_tag_bits. 844 Suppose an adversary wishes to introduce a forged or altered packet 845 into a target network by randomly selecting an authentication value 846 until by chance they hit a valid authentication tag. The table below 847 summarizes the relationship between the number of forged packets the 848 adversary has tried, the size of the authentication tag, and the 849 probability of a compromise occurring (i.e. at least one of the 850 attempted forgeries having a valid authentication tag). The reader 851 is reminded that the forgery attempts can be made over the entire 852 network, not just a single link, and that frequently changing the key 853 does not decrease the probability of a compromise occurring. 855 +==================+========================================+ 856 | Authentication | Probability of a Compromise Occurring | 857 | Tag | for a given number of forgery attempts | 858 | Size |------------+-------------+-------------| 859 | (octets) | prob=2^-30 | prob=2^-20 | prob=2^-10 | 860 |==================+=============+=============+============| 861 | 4 | 2^2 tries | 2^12 tries | 2^22 tries | 862 |==================+============+=============+=============| 863 | 8 | 2^34 tries | 2^44 tries | 2^54 tries | 864 |==================+============+=============+=============| 865 | 12 | 2^66 tries | 2^76 tries | 2^86 tries | 866 |==================+============+=============+=============| 867 | 16 | 2^98 tries | 2^108 tries | 2^118 tries | 868 +=================+============+=============+==============+ 870 Table 3: Probability of a compromise occurring for a given 871 number of forgery attempts and tag size. 873 14. IANA Considerations 875 14.1. SDES 877 Security description [RFC 4568] defines SRTP "crypto suites"; a 878 crypto suite corresponds to a particular AEAD algorithm in SRTP. In 879 order to allow SDP to signal the use of the algorithms defined in 880 this document, IANA will register the following crypto suites into 881 the subregistry for SRTP crypto suites under the SRTP transport of 882 the SDP Security Descriptions: 884 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 885 "AEAD_AES_256_GCM" / 886 "AEAD_AES_128_GCM_8" / 887 "AEAD_AES_256_GCM_8" / 888 "AEAD_AES_128_GCM_12" / 889 "AEAD_AES_256_GCM_12" / 890 "AEAD_AES_128_CCM" / 891 "AEAD_AES_256_CCM" / 892 srtp-crypto-suite-ext 894 14.2. DTLS 896 DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; it 897 also corresponds to the use of an AEAD algorithm in SRTP. In order 898 to allow the use of the algorithms defined in this document in 899 DTLS-SRTP, we request IANA register the following SRTP Protection 900 Profiles: 902 AEAD_AES_128_CCM 903 cipher: AES_128_CCM 904 cipher_key_length: 128 bits 905 cipher_salt_length: 96 bits 906 aead_auth_tag_length: 16 octets 907 auth_function: NULL 908 auth_key_length: N/A 909 auth_tag_length: N/A 910 maximum lifetime: at most 2^31 SRTCP packets and 911 at most 2^48 SRTP packets 913 AEAD_AES_256_CCM 914 cipher: AES_256_CCM 915 cipher_key_length: 256 bits 916 cipher_salt_length: 96 bits 917 aead_auth_tag_length: 16 octets 918 auth_function: NULL 919 auth_key_length: N/A 920 auth_tag_length: N/A 921 maximum lifetime: at most 2^31 SRTCP packets and 922 at most 2^48 SRTP packets 924 AEAD_AES_128_CCM_8 925 cipher: AES_128_CCM 926 cipher_key_length: 128 bits 927 cipher_salt_length: 96 bits 928 aead_auth_tag_length: 8 octets 929 auth_function: NULL 930 auth_key_length: N/A 931 auth_tag_length: N/A 932 maximum lifetime: at most 2^31 SRTCP packets and 933 at most 2^48 SRTP packets 935 AEAD_AES_256_CCM_8 936 cipher: AES_256_CCM 937 cipher_key_length: 256 bits 938 cipher_salt_length: 96 bits 939 aead_auth_tag_length: 8 octets 940 auth_function: NULL 941 auth_key_length: N/A 942 auth_tag_length: N/A 943 maximum lifetime: at most 2^31 SRTCP packets and 944 at most 2^48 SRTP packets 946 AEAD_AES_128_CCM_12 947 cipher: AES_128_CCM 948 cipher_key_length: 128 bits 949 cipher_salt_length: 96 bits 950 aead_auth_tag_length: 12 octets 951 auth_function: NULL 952 auth_key_length: N/A 953 auth_tag_length: N/A 954 maximum lifetime: at most 2^31 SRTCP packets and 955 at most 2^48 SRTP packets 957 AEAD_AES_256_CCM_12 958 cipher: AES_256_CCM 959 cipher_key_length: 256 bits 960 cipher_salt_length: 96 bits 961 aead_auth_tag_length: 12 octets 962 auth_function: NULL 963 auth_key_length: N/A 964 auth_tag_length: N/A 965 maximum lifetime: at most 2^31 SRTCP packets and 966 at most 2^48 SRTP packets 968 AEAD_AES_128_GCM 969 cipher: AES_128_GCM 970 cipher_key_length: 128 bits 971 cipher_salt_length: 96 bits 972 aead_auth_tag_length: 16 octets 973 auth_function: NULL 974 auth_key_length: N/A 975 auth_tag_length: N/A 976 maximum lifetime: at most 2^31 SRTCP packets and 977 at most 2^48 SRTP packets 979 AEAD_AES_256_GCM 980 cipher: AES_256_GCM 981 cipher_key_length: 256 bits 982 cipher_salt_length: 96 bits 983 aead_auth_tag_length: 16 octets 984 auth_function: NULL 985 auth_key_length: N/A 986 auth_tag_length: N/A 987 maximum lifetime: at most 2^31 SRTCP packets and 988 at most 2^48 SRTP packets 990 AEAD_AES_128_GCM_8 991 cipher: AES_128_GCM 992 cipher_key_length: 128 bits 993 cipher_salt_length: 96 bits 994 aead_auth_tag_length: 8 octets 995 auth_function: NULL 996 auth_key_length: N/A 997 auth_tag_length: N/A 998 maximum lifetime: at most 2^31 SRTCP packets and 999 at most 2^48 SRTP packets 1001 AEAD_AES_256_GCM_8 1002 cipher: AES_256_GCM 1003 cipher_key_length: 256 bits 1004 cipher_salt_length: 96 bits 1005 aead_auth_tag_length: 8 octets 1006 auth_function: NULL 1007 auth_key_length: N/A 1008 auth_tag_length: N/A 1009 maximum lifetime: at most 2^31 SRTCP packets and 1010 at most 2^48 SRTP packets 1012 AEAD_AES_128_GCM_12 1013 cipher: AES_128_GCM 1014 cipher_key_length: 128 bits 1015 cipher_salt_length: 96 bits 1016 aead_auth_tag_length: 12 octets 1017 auth_function: NULL 1018 auth_key_length: N/A 1019 auth_tag_length: N/A 1020 maximum lifetime: at most 2^31 SRTCP packets and 1021 at most 2^48 SRTP packets 1023 AEAD_AES_256_GCM_12 1024 cipher: AES_256_GCM 1025 cipher_key_length: 256 bits 1026 cipher_salt_length: 96 bits 1027 aead_auth_tag_length: 12 octets 1028 auth_function: NULL 1029 auth_key_length: N/A 1030 auth_tag_length: N/A 1031 maximum lifetime: at most 2^31 SRTCP packets and 1032 at most 2^48 SRTP packets 1034 Note that these SRTP Protection Profiles do not specify an 1035 auth_function, auth_key_length, or auth_tag_length because all of 1036 these profiles use AEAD algorithms, and thus do not use a separate 1037 auth_function, auth_key, or auth_tag. The term aead_auth_tag_length 1038 is used to emphasize that this refers to the authentication tag 1039 provided by the AEAD algorithm and that this tag is not located in 1040 the authentication tag field provided by SRTP/SRTCP. 1042 14.3. MIKEY 1044 In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], 1045 IANA maintains several Payload Name Spaces under Multimedia Internet 1046 KEYing (MIKEY). This document requires additions to two of the lists 1047 maintained under MIKEY Security Protocol Parameters. 1049 On the SRTP policy Type/Value list (derived from Table 6.10.1.a of 1050 [RFC3830]) we request the following addition: 1052 Type | Meaning | Possible values 1053 ---------------------------------------------------------------- 1054 TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) 1056 On the Encryption Algorithm List (derived from Table 6.10.1.b of 1057 [RFC3830]) we request the following additions: 1059 SRTP encr alg. | Value | Default Session Encr. Key Length 1060 ----------------------------------------------------------- 1061 AES-CCM | TBD | 16 octets 1062 AES-GCM | TBD | 16 octets 1064 The SRTP encryption algorithm, session encryption key length, and 1065 AEAD authentication tag values received from MIKEY fully determine 1066 the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is 1067 described in section 15. 1069 14.4. AEAD registry 1071 We request that IANA make the following additions to the AEAD 1072 registry: 1074 AEAD_AES_128_CCM_12 = TBD 1075 AEAD_AES_256_CCM_12 = TBD 1077 15. Parameters for use with MIKEY 1079 MIKEY specifies the algorithm family separately from the key length 1080 (which is specified by the Session Encryption key length ) and the 1081 authentication tag length (specified by AEAD Auth. tag length). 1083 +------------+-------------+-------------+ 1084 | Encryption | Encryption | AEAD Auth. | 1085 | Algorithm | Key Length | Tag Length | 1086 +============+=============+=============+ 1087 AEAD_AES_128_GCM | AES-GCM | 16 octets | 16 octets | 1088 +------------+-------------+-------------+ 1089 AEAD_AES_128_CCM | AES-CCM | 16 octets | 16 octets | 1090 +------------+-------------+-------------+ 1091 AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets | 1092 +------------+-------------+-------------+ 1093 AEAD_AES_128_CCM_12 | AES-CCM | 16 octets | 12 octets | 1094 +------------+-------------+-------------+ 1095 AEAD_AES_128_GCM_8 | AES-GCM | 16 octets | 8 octets | 1096 +------------+-------------+-------------+ 1097 AEAD_AES_128_CCM_8 | AES-CCM | 16 octets | 8 octets | 1098 +------------+-------------+-------------+ 1099 AEAD_AES_256_GCM | AES-GCM | 32 octets | 16 octets | 1100 +------------+-------------+-------------+ 1101 AEAD_AES_256_CCM | AES-CCM | 32 octets | 16 octets | 1102 +------------+-------------+-------------+ 1103 AEAD_AES_256_GCM_12 | AES-GCM | 32 octets | 12 octets | 1104 +------------+-------------+-------------+ 1105 AEAD_AES_256_CCM_12 | AES-CCM | 32 octets | 12 octets | 1106 +------------+-------------+-------------+ 1107 AEAD_AES_256_GCM_8 | AES-GCM | 32 octets | 8 octets | 1108 +------------+-------------+-------------+ 1109 AEAD_AES_256_CCM_8 | AES-CCM | 32 octets | 8 octets | 1110 +============+=============+=============+ 1112 Table 4: Mapping MIKEY parameters to AEAD algorithm 1114 Section 12 in this document restricts the choice of Key Derivation 1115 Function for AEAD algorithms. To enforce this restriction in MIKEY, 1116 we require that the SRTP PRF has value AES-CM whenever an AEAD 1117 algorithm is used. Note that, according to Section 6.10.1 in 1118 [RFC3830], the key length of the Key Derivation Function (i.e. the 1119 SRTP master key length) is always equal to the session encryption key 1120 length. This means, for example, that AEAD_AES_256_GCM will use 1121 AES_256_CM_PRF as the Key Derivation Function. 1123 16. Acknowledgements 1125 The authors would like to thank Michael Peck, Michael Torla, Qin Wu, 1126 Magnus Westerland, Oscar Ohllson and many other reviewers who 1127 provided valuable comments on earlier drafts of this document. 1129 17. References 1131 17.1. Normative References 1133 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 1134 Mode for Authentication and Confidentiality", U.S. 1135 National Institute of Standards and Technology http:// 1136 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 1138 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 1139 Recommendation for Block Cipher Modes of Operation: 1140 Galois/Counter Mode (GCM) and GMAC.", U.S. National 1141 Institute of Standards and Technology http:// 1142 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, March 1997. 1147 [RFC3550] Casner, S., Frederick, R., and V. Jacobson, "RTP: A 1148 Transport Protocol for Real-Time Applications", RFC 3550, 1149 July 2003. 1151 [RFC3610] Whiting,D., Housley, R., and N. Ferguson, "Counter with 1152 CBC-MAC (CCM)", RFC 3610, March 2004. 1154 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 1155 K. Norrman, "The Secure Real-time Transport Protocol 1156 (SRTP)", RFC 3711, September 2003. 1158 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and 1159 Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1160 August 2004. 1162 [RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session 1163 Description Protocol (SDP): Security Descriptions for 1164 Media Streams", RFC 4568, July 2006. 1166 [RFC5116] McGrew, D., "An Interface and Algorithms for 1167 Authenticated Encryption with Associated Data", RFC 5116, 1168 January 2008. 1170 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 1171 Algorithms with the Encrypted Payload of the Internet Key 1172 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. 1174 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1175 Security (DTLS) Extension to Establish Keys for the Secure 1176 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1178 [RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP" 1179 RFC 6188, March 2011. 1181 [RFC6655] McGrew,D. and D. Bailey,"AES-CCM Cipher Suites for Transport 1182 Layer Security (TLS)", July 2012. 1184 [RFCXXXX] J. Lennox, "Encryption of Header Extensions in the Secure 1185 Real-Time Transport", January 2013. 1187 17.2. Informative References 1189 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 1190 Relations among notions and analysis of the generic 1191 composition paradigm", Proceedings of ASIACRYPT 2000, 1192 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 1193 www-cse.ucsd.edu/users/mihir/papers/oem.html. 1195 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication 1196 and Key Establishment", Springer, 2003 . 1198 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 1199 CryptoToolkit/modes/800-38_Series_Publications/ 1200 SP800-38B.pdf. 1202 [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and 1203 provably repairing the SSH authenticated encryption 1204 scheme: A case study of the Encode-then-Encrypt-and-MAC 1205 paradigm", ACM Transactions on Information and System Secu 1206 rity, http://www-cse.ucsd.edu/users/tkohno/papers/ 1207 TISSEC04/. 1209 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 1210 than Real: Security Challenges in Virtual Machine Based 1211 Computing Environments", Proceedings of the 10th Workshop 1212 on Hot Topics in Operating Systems http:// 1213 www.stanford.edu/~talg/papers/HOTOS05/ 1214 virtual-harder-hotos05.pdf. 1216 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", 1217 Proceedings of the 9th Annual Workshop on Selected Areas 1218 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/ 1219 proposedmodes/ccm/ccm-ad1.pdf, 2002. 1221 [MODES] Dworkin, M., "NIST Special Publication 800-38: 1222 Recommendation for Block Cipher Modes of Operation", U.S. 1223 National Institute of Standards and Technology http:// 1224 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 1226 [MV04] McGrew, D. and J. Viega, "The Security and Performance of 1227 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT 1228 '04, http://eprint.iacr.org/2004/193, December 2004. 1230 [R02] Rogaway, P., "Authenticated encryption with Associated- 1231 Data", ACM Conference on Computer and Communication 1232 Security (CCS'02), pp. 98-107, ACM Press, 1233 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 1235 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1236 Hashing for Message Authentication", RFC 2104, 1237 February 1997. 1239 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1240 Jacobson, "RTP: A Transport Protocol for Real-Time 1241 Applications", STD 64, RFC 3550, July 2003. 1243 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1244 Requirements for Security", BCP 106, RFC 4086, June 2005. 1246 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1247 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1248 RFC 4106, June 2005. 1250 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1251 Key Management", BCP 107, RFC 4107, June 2005. 1253 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1254 RFC 4303, December 2005. 1256 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1257 Mode with IPsec Encapsulating Security Payload (ESP)", 1258 RFC 4309, December 2005. 1260 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1261 Transform Carrying Roll-Over Counter for the Secure Real- 1262 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1264 Author's Address 1266 David A. McGrew 1267 Cisco Systems, Inc. 1268 510 McCarthy Blvd. 1269 Milpitas, CA 95035 1270 US 1271 Phone: (408) 525 8651 1272 Email: mcgrew@cisco.com 1273 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1275 Kevin M. Igoe 1276 NSA/CSS Commercial Solutions Center 1277 National Security Agency 1278 EMail: kmigoe@nsa.gov 1280 Acknowledgement 1282 Funding for the RFC Editor function is provided by the IETF 1283 Administrative Support Activity (IASA).