idnits 2.17.1 draft-ietf-avtcore-srtp-aes-gcm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 3 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 (June 25, 2012) is 4313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4568' is mentioned on line 773, but not defined == Unused Reference: 'CCM' is defined on line 970, but no explicit reference was found in the text == Unused Reference: 'RFC4568' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC6188' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: 'BOYD' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'CMAC' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'EEM04' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'GR05' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'J02' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'MV04' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 1066, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1076, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet Draft Cisco Systems, Inc. 4 Intended Status: Informational K.M. Igoe 5 Expires: December 27, 2012 National Security Agency 6 June 25, 2012 8 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 9 draft-ietf-avtcore-srtp-aes-gcm-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on December 27, 2012. 28 Copyright Notice 30 Copyright (c) 2012 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document defines how AES-GCM, AES-CCM, and other Authenticated 46 Encryption with Associated Data (AEAD) algorithms can be used to 47 provide confidentiality and data authentication mechanisms in the 48 SRTP protocol. 50 Table of Contents 52 1. Introduction.....................................................3 53 2. Conventions Used In This Document................................3 54 3. Overview of the SRTP/SRTCP Security Architecture.................4 55 4. Terminology......................................................4 56 5. Generic AEAD Processing..........................................5 57 5.1. Types of Input Data.........................................5 58 5.2. AEAD Invocation Inputs and Outputs..........................5 59 5.2.1. Encrypt Mode...........................................5 60 5.2.2. Decrypt Mode...........................................6 61 5.3. Handling of AEAD Authentication.............................6 62 6. Counter Mode Encryption..........................................6 63 7. Unneeded SRTP/SRTCP Fields.......................................7 64 7.1. SRTP/SRTCP Authentication Field.............................7 65 7.2. RTP Padding.................................................7 66 8. AES-GCM/CCM processing for SRTP..................................7 67 8.1. SRTP IV formation for AES-GCM and AES-CCM...................7 68 8.2. Data Types in SRTP Packets..................................8 69 8.3. Prevention of SRTP IV Reuse.................................9 70 9. AES-GCM/CCM Processing of SRTCP Compound Packets................10 71 9.1. SRTCP IV formation for AES-GCM and AES-CCM.................10 72 9.2. Data Types in Encrypted SRTCP Compound Packets.............10 73 9.3. Data Types in Unencrypted SRTCP Compound Packets...........12 74 9.4. Prevention of SRTCP IV Reuse...............................13 75 10. Constraints on AEAD for SRTP and SRTCP.........................13 76 10.1. Generic AEAD Parameter Constraints........................13 77 10.2. AES-GCM for SRTP/SRTCP....................................14 78 10.3. AES-CCM for SRTP/SRTCP....................................14 79 11. Key Derivation Functions.......................................15 80 12. Security Considerations........................................15 81 12.1. Handling of Security Critical Parameters..................15 82 12.2. Size of the Authentication Tag............................15 83 13. IANA Considerations............................................16 84 13.1. SDES......................................................16 85 13.2. DTLS......................................................17 86 13.3. MIKEY.....................................................19 87 14. Parameters for use with MIKEY..................................19 88 15. Acknowledgements...............................................20 89 16. References.....................................................21 90 16.1. Normative References......................................21 91 16.2. Informative References....................................22 93 1. Introduction 95 The Secure Real-time Transport Protocol (SRTP) is a profile of the 96 Real-time Transport Protocol (RTP), which can provide 97 confidentiality, message authentication, and replay protection to the 98 RTP traffic and to the control traffic for RTP, the Real-time 99 Transport Control Protocol (RTCP). It is important to note that the 100 outgoing SRTP packets from a single endpoint may be originating from 101 several independent data sources. 103 Authenticated encryption [BN00] is a form of encryption that, in 104 addition to providing confidentiality for the plaintext that is 105 encrypted, provides a way to check its integrity and authenticity. 106 Authenticated Encryption with Associated Data, or AEAD [R02], adds 107 the ability to check the integrity and authenticity of some 108 Associated Data (AD), also called "additional authenticated data", 109 that is not encrypted. This specification makes use of the interface 110 to a generic AEAD algorithm as defined in [RFC5116]. 112 The Advanced Encryption Standard (AES) is a block cipher that 113 provides a high level of security, and can accept different key 114 sizes. Two families of AEAD algorithm families, AES Galois/Counter 115 Mode (AES-GCM) and AES Counter with Cipher Block Chaining-Message 116 Authentication Code (AES-CCM), are based upon AES. This 117 specification makes use of the AES versions that use 128-bit and 118 256-bit keys, which we call AES-128 and AES-256, respectively. 120 The Galois/Counter Mode of operation (GCM) and the Counter with 121 Cipher Block Chaining-Message Authentication Code mode of operation 122 (CCM) are both AEAD modes of operation for block ciphers. Both use 123 counter mode to encrypt the data, an operation that can be 124 efficiently pipelined. Further, GCM authentication uses operations 125 that are particularly well suited to efficient implementation in 126 hardware, making it especially appealing for high-speed 127 implementations, or for implementations in an efficient and compact 128 circuit. CCM is well suited for use in compact software 129 implementations. This specification uses GCM and CCM with both 130 AES-128 and AES-256. 132 In summary, this document defines how to use AEAD algorithms, 133 particularly AES-GCM and AES-CCM, to provide confidentiality and 134 message authentication within SRTP and SRTCP packets. 136 2. Conventions Used In This Document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Overview of the SRTP/SRTCP Security Architecture 144 SRTP/SRTCP security is based upon the following principles: 146 a) Both privacy and authentication are based upon the use of 147 symmetric algorithms. An AEAD algorithm such as AES-CCM and 148 AES-GCM combines privacy and authentication into a single 149 process. 151 b) A secret master key is shared by all participating endpoints, 152 both those originating SRTP/SRTCP packets and those receiving 153 these packets. Any given master key MAY be used 154 simultaneously by several endpoints to originate SRTP/SRTCP 155 packets (as well one or more endpoints using this master key 156 to process inbound data). 158 c) A Key Derivation Function is applied to the shared master key 159 value to form separate encryption keys, authentication keys 160 and salting keys for SRTP and for SRTCP (a total of six 161 keys). This process is described in sections 4.3.1 and 4.3.3 162 of [RFC3711]. Since AEAD algorithms such as AES-CCM and 163 AES-GCM combine encryption and authentication into a single 164 process, AEAD algorithms do not make use of the 165 authentication keys. The master key MUST be at least as 166 large as the encryption key derived from it. 168 4. Terminology 170 The following terms have very specific meanings in the context of 171 this RFC: 173 Crypto Context For the purposes of this document, a crypto 174 context is the outcome of any process which 175 results in authentication of each endpoint in the 176 SRTP session and possession by each endpoint of a 177 shared secret master key. Various encryption 178 keys, authentication keys and salts are derived 179 from the master key. Aside from making 180 modifications to IANA registries to allow AES-GCM 181 and AES-CCM to work with SDES, DTLS and MIKEY, the 182 details of how the master key is established are 183 outside the scope of this document. Similarly any 184 mechanism for rekeying an existing Cipher Context 185 is outside the scope of the document. 187 Instantiation In AEAD, an instantiation is an (Encryption_key, 188 salt) pair together with all of the data 189 structures (for example, counters) needed for it 190 to function properly. In SRTP/SRTCP, each 191 endpoint will need two instantiations of the AEAD 192 algorithm for each master key in its possession, 193 one for SRTP and one for SRTCP. 195 Invocation SRTP/SRTCP data streams are broken into packets. 196 Each packet is processed by a single invocation of 197 the appropriate instantiation of the AEAD 198 algorithm. 200 In many applications, each endpoint will have one master key for 201 processing outbound data but may have one or more separate master 202 keys for processing inbound data. 204 5. Generic AEAD Processing 206 5.1. Types of Input Data 208 Associated Data This is data that is to be authenticated but 209 not encrypted. 211 Plaintext Data that is to be both encrypted and 212 authenticated. 214 Raw Data Data that is to be neither encrypted nor 215 authenticated. 217 Which portions of SRTP/SRTCP packets that are to be treated as 218 associated data, which are to be treated as plaintext, and which are 219 to be treated as raw data are covered in sections 8.2, 9.2 and 9.3. 221 5.2. AEAD Invocation Inputs and Outputs 223 5.2.1. Encrypt Mode 225 Inputs: 226 Encryption_key Octet string, either 16 or 32 227 octets long 228 Initialization_Vector Octet string, 12 octets long 229 Associated_Data Bit string of variable length 230 Plaintext Bit string of variable length 231 Tag_Size_Flag (CCM only*) One Octet 233 Outputs 234 Ciphertext Bit string, length = 235 length(ciphertext)-tag_length 237 (*) For GCM, the algorithm choice determines the tag size. 239 AES-CCM uses a Tag_Size_Flag that has the hex value 5A if an 8-octet 240 authentication tag is used, 6A if a 12-octet authentication tag is 241 used, and 7A if a 16-octet authentication tag is used. 243 5.2.2. Decrypt Mode 245 Inputs: 246 Encryption_key Octet string, either 16 or 32 247 octets long 248 Initialization_Vector octet string, 12 octets long 249 Associated_Data Bit string of variable length 250 Ciphertext Bit string of variable length 251 Tag_Size_Flag (CCM only*) One Octet 253 Outputs 254 Plaintext Bit string, length = 255 length(ciphertext)-tag_length 256 Validity_Flag Boolean, TRUE if valid, 257 FALSE otherwise 259 (*) For GCM, the algorithm choice determines the tag size. 261 AES-CCM uses a Tag_Size_Flag that has the hex value 5A if an 8-octet 262 authentication tag is used, 6A if a 12-octet authentication tag is 263 used, and 7A if a 16-octet authentication tag is used. 265 5.3. Handling of AEAD Authentication 267 AEAD requires that all incoming packets MUST pass AEAD authentication 268 before any other action takes place. The ciphertext MUST NOT be 269 decrypted until the AEAD tag has been validated. The associated data 270 MUST NOT be released until the AEAD tag has been validated. 272 Should the AEAD tag prove to be invalid, the incoming data is to be 273 discarded and appropriate error flags raised. Local policy 274 determines how these flags are to be handled and are outside the 275 scope of this document. 277 6. Counter Mode Encryption 279 Each outbound packet uses a 12 octet IV and encryption key to form a 280 keystream of bits which is XORed to the plaintext to form cipher. 281 Using the 12-octet IV and a 4-octet block counter, the keystream is 282 formed in 16-octet blocks until it is at least as long as the 283 plaintext, and any excess keystream bits are discarded. At the start 284 of each packet, the block counter is initialized to 0x0000 for 285 AES-CCM and to 0x0001 for AES-GCM. A key block is formed by 287 key_block = AES_ENC( IV || block_counter; key=Encryption_key ) 289 and the block counter is incremented. This allows for a per packet 290 keystream of length of up to 2^36 octets for AES-CCM and up to 291 2^36-16 octets for AES-GCM. 293 With any counter mode, if the same (IV, Encryption_key) pair is used 294 twice, precisely the same keystream is formed. As explained in 295 section 9.1 of RFC 3711, this is a cryptographic disaster. For 296 AES-GCM, the consequences of such a reuse are even worse than 297 explained in RFC 3711 because it would completely compromise the 298 AES-GCM authentication mechanism. 300 7. Unneeded SRTP/SRTCP Fields 302 AEAD counter mode encryption removes the need for certain existing 303 SRTP/SRTCP mechanisms. 305 7.1. SRTP/SRTCP Authentication Field 307 The AEAD message authentication mechanism MUST be the primary message 308 authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP 309 authentication mechanisms SHOULD NOT be used with any AEAD algorithm 310 and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED 311 and SHOULD NOT be present. Note that this contradicts section 3.4 of 312 [RFC3711] which makes the use of the SRTCP Authentication field 313 mandatory, but the presence of the AEAD authentication renders the 314 older authentication methods redundant. 316 Rationale. Some applications use the SRTP/SRTCP Authentication 317 Tag as a means of conveying additional information, notably 318 [RFC4771]. This document retains the Authentication Tag field 319 primarily to preserve compatibility with these applications. 321 7.2. RTP Padding 323 Neither AES-GCM not AES-CCM requires that the data be padded out to a 324 specific block size, reducing the need to ude the padding mechanism 325 provided by RTP. It is RECOMENDED that the RTP padding mechanism not 326 be used unless it is necessary to disguise the length of the 327 underlying plaintext. 329 8. AES-GCM/CCM processing for SRTP 331 8.1. SRTP IV formation for AES-GCM and AES-CCM 333 The 12 byte initialization vector used by both AES-GCM and AES-CCM 334 SRTP is formed by first concatenating 2-octets of zeroes, the 4-octet 335 SSRC, the 4-octer Rollover Counter (ROS) and the two octet sequence 336 number SEQ. The resulting 12-octet value is then XORed to the 337 12-octet salt to form the 12-octet IV. 339 0 0 0 0 0 0 0 0 0 0 1 1 340 0 1 2 3 4 5 6 7 8 9 0 1 341 +--+--+--+--+--+--+--+--+--+--+--+--+ 342 |00|00| SSRC | ROC | SEQ |---+ 343 +--+--+--+--+--+--+--+--+--+--+--+--+ | 344 | 345 +--+--+--+--+--+--+--+--+--+--+--+--+ | 346 | Encryption Salt |->(+) 347 +--+--+--+--+--+--+--+--+--+--+--+--+ | 348 | 349 +--+--+--+--+--+--+--+--+--+--+--+--+ | 350 | Initialization Vector |<--+ 351 +--+--+--+--+--+--+--+--+--+--+--+--+ 353 Figure 1: AES-GCM and AES-CCM SRTP 354 Initialization Vector formation. 356 Using the terminology of section 8.2.1. of [GCM], the first six 357 octets of the IV are the fixed field and the last six bytes are the 358 invocation field. 360 8.2. Data Types in SRTP Packets 362 All SRTP packets MUST be both authenticated and encrypted. The data 363 fields within the SRTP packets are broken into Associated Data, 364 Plaintext and Raw Data as follows (see figure 2): 366 Associated Data The version (2 bits), padding flag (1 bit), 367 extension flag (1 bit), CSRC count (4 bits), 368 sequence number (16 bits), timestamp (32 bits), 369 SSRC (32 bits), optional contributing source 370 identifiers (CSRCs, 32 bits each), and optional 371 RTP extension (32 bits). 373 Plaintext The RTP payload (variable length), RTP padding (if 374 used, variable length), and RTP pad count ( if 375 used, 8 bits). 377 Raw Data The optional 32-bit SRTP MKI and the 32-bit SRTP 378 authentication tag (whose use is NOT 379 RECOMMENDED). 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 A |V=2|P|X| CC |M| Packet Type | sequence number | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 A | timestamp | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 A | synchronization source (SSRC) identifier | 389 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 390 A | contributing source (CSRC) identifiers (optional) | 391 A | .... | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 A | RTP extension (OPTIONAL) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 P | payload ... | 396 P | +-------------------------------+ 397 P | | RTP padding | RTP pad count | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 R : SRTP MKI (optional) : 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 R : authentication tag (NOT RECOMMENDED) : 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 P = Plaintext (to be encrypted and authenticated) 405 A = Associated Data (to be authenticated only) 406 R = neither encrypted nor authenticated 408 Note: The RTP padding and RTP padding count fields are optional 409 and are not recommended 411 Figure 2: AEAD inputs from an SRTP packet. 413 8.3. Prevention of SRTP IV Reuse 415 In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC) 416 triple is never used twice with the same master key. There are two 417 phases to this issue. 419 Counter Management A rekey MUST be performed to establish a new 420 master key before the (ROC,SEQ) pair cycles back 421 to its original value. 423 SSRC Management The set of all SSRC values must be partitioned 424 into disjoint pools, one pool for each endpoint 425 using the master key to originate outbound 426 data. Each such endpoint MUST only issue SSRC 427 values from the pool it has been assigned. 428 Further, each endpoint MUST maintain a history 429 of outbound SSRC identifiers that it has issued 430 within the lifetime of the current master key, 431 and when a new synchronization source requests 432 an SSRC identifier it MUST NOT be given an 433 identifier that has been previously issued. A 434 rekey MUST be performed before its pool of SSRC 435 values is exhausted. 437 9. AES-GCM/CCM Processing of SRTCP Compound Packets 439 All SRTCP compound packets MUST be authenticated, but unlike SRTP, 440 SRTCP packet encryption is optional. A sender can select which 441 packets to encrypt, and indicates this choice with a 1-bit encryption 442 flag (located just before the 31-bit SRTCP index) 444 9.1. SRTCP IV formation for AES-GCM and AES-CCM 446 The 12 byte initialization vector used by both AES-GCM and AES-CCM 447 SRTCP is formed by first concatenating 2-octets of zeroes, the 448 4-octet Synchronization Source identifier (SSRC), 2-octets of zeroes, 449 a single zero bit, and the 31-bit SRTCP Index. The resulting 450 12-octet value is then XORed to the 12-octet salt to form the 451 12-octet IV. 453 0 1 2 3 4 5 6 7 8 9 10 11 454 +--+--+--+--+--+--+--+--+--+--+--+--+ 455 |00|00| SSRC |00|00|0+SRTCP Idx|---+ 456 +--+--+--+--+--+--+--+--+--+--+--+--+ | 457 | 458 +--+--+--+--+--+--+--+--+--+--+--+--+ | 459 | Encryption Salt |->(+) 460 +--+--+--+--+--+--+--+--+--+--+--+--+ | 461 | 462 +--+--+--+--+--+--+--+--+--+--+--+--+ | 463 | Initialization Vector |<--+ 464 +--+--+--+--+--+--+--+--+--+--+--+--+ 466 Figure 3: SRTCP Initialization Vector formation. 468 Using the terminology of section 8.2.1. of [GCM], the first eight 469 octets of the IV are the fixed field and the last four bytes are the 470 invocation field. 472 9.2. Data Types in Encrypted SRTCP Compound Packets 474 When the encryption flag is set to 1, the SRTCP packet is broken into 475 plaintext, associated data, and raw (untouched) data as listed below 476 (see figure 4): 478 Associated Data The packet version (2 bits), padding flag (1 bit), 479 reception report count (5 bits), packet type (8 480 bits), length (2 octets), SSRC (4 octets), 481 encryption flag (1 bit) and SRTCP index (31 482 bits). 484 Raw Data The 32-bit optional SRTCP MKI index and 32-bit 485 SRTCP authentication tag (whose use is NOT 486 RECOMMENDED). 488 Plaintext All other data. 490 Note that the plaintext comes in one contiguous field. Since the 491 AEAD cipher is larger than the plaintext by exactly the length of the 492 AEAD authentication tag, the corresponding STRCP encrypted packet 493 replaces the plaintext field with a slightly larger field containing 494 the cipher. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 A |V=2|P| RC | Packet Type | length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 A | synchronization source (SSRC) of Sender | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 P | sender info | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 P | report block 1 | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 P | report block 2 | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 P | ... | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 P |V=2|P| SC | Packet Type | length | 512 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 513 P | SSRC/CSRC_1 | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 P | SDES items | 516 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 517 P | ... | 518 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 519 A |1| SRTCP index | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 R | SRTCP MKI (optional) index | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 R : authentication tag (NOT RECOMMENDED) : 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 P = Plaintext (to be encrypted and authenticated) 527 A = Associated Data (to be authenticated only) 528 R = neither encrypted nor authenticated 530 Figure 4: AEAD SRTCP inputs when encryption flag = 1. 532 9.3. Data Types in Unencrypted SRTCP Compound Packets 534 When the encryption flag is set to 0, the SRTCP compound packet is 535 broken into plaintext, associated data, and raw (untouched) data as 536 follows (see figure 5): 538 Plaintext None. 540 Raw Data The 32-bit optional SRTCP MKI index and 32-bit 541 SRTCP authentication tag (whose use is NOT 542 RECOMMENDED). 544 Associated Data All other data. 546 Even though there is no plaintext in this RTCP packet, AEAD 547 encryption returns a cipher field which is precisely the length of 548 the AEAD authentication tag. This cipher is to be placed before the 549 Encryption flag and the SRTCP index in the authenticated SRTCP 550 packet. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 A |V=2|P| RC | Packet Type | length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 A | synchronization source (SSRC) of Sender | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 A | sender info | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 A | report block 1 | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 A | report block 2 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 A | ... | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 A |V=2|P| SC | Packet Type | length | 568 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 569 A | SSRC/CSRC_1 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 A | SDES items | 572 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 573 A | ... | 574 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 575 A |0| SRTCP index | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 R | SRTCP MKI (optional)index | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 R : authentication tag (NOT RECOMMENDED) : 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 A = Associated Data (to be authenticated only) 583 R = neither encrypted nor authenticated 585 Figure 5: AEAD SRTCP inputs when encryption flag = 0. 587 9.4. Prevention of SRTCP IV Reuse 589 A new master key MUST be established before the 31-bit SRTCP index 590 cycles back to its original value. Ideally a rekey performed should 591 be performed and a new master key in place and well before the SRTCP 592 index overflows. 594 The comments on SSRC management in section 8.3 also apply. 596 10. Constraints on AEAD for SRTP and SRTCP 598 In general, any AEAD algorithm can accept inputs with varying 599 lengths, but each algorithm can accept only a limited range of 600 lengths for a specific parameter. In this section, we describe the 601 constraints on the parameter lengths that any AEAD algorithm must 602 support to be used in AEAD-SRTP. Additionally we specify a complete 603 parameter set for two specific AEAD algorithms, namely AES-GCM and 604 AES-CCM. 606 10.1. Generic AEAD Parameter Constraints 608 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three 609 constraints listed below: 611 PARAMETER Meaning Value 613 A_MAX maximum additional MUST be at least 12 octets 614 authenticated data 615 length 616 N_MIN minimum nonce (IV) MUST be no more than 12 octets 617 length 618 N_MAX maximum nonce (IV) MUST be at least 12 octets 619 length 620 C_MAX maximum ciphertext MUST be at most 2^36-16 octets 621 length per invocation C_max values less than 2232 622 are discouraged 624 The upper bound on C_MAX are based on purely cryptographic 625 considerations. The lower bound on C_MAX is obtained by subtracting 626 away a 20-octet IP header, 8-octet UDP header, and 12-octet RTP 627 header from the maximum transmission unit (MTU) of 2272. 629 For sake of clarity we specify two additional parameters: 631 Authentication Tag Length MUST be either 8, 12, or 16 632 octets 633 Maximum number of invocations MUST be at most 2^48 for SRTP 634 for a given instantiation MUST be at most 2^31 for SRTCP 635 Block Counter size MUST be 32 bits 637 The reader is reminded that the plaintext is shorter than the 638 ciphertext by exactly the length of the AEAD authentication tag. 640 10.2. AES-GCM for SRTP/SRTCP 642 AES-GCM is a family of AEAD algorithms built around the AES block 643 cipher algorithm. AES-GCM uses AES counter mode for encryption and 644 Galois Message Authentication Code (GMAC) for authentication. A 645 detailed description of the AES-GCM family can be found in 646 [RFC5116]. The following members of the AES-GCM family may be used 647 with SRTP/SRTCP: 649 Table 1: AES-GCM algorithms for SRTP/SRTCP 650 Name Key Size Auth. Tag Size Reference 651 ================================================================ 652 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 653 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 654 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 655 AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] 656 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 657 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 659 Any implementation of AES-GCM SRTP SHOULD support both 660 AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8, and it MAY support the 661 four other variants shown table 1. 663 10.3. AES-CCM for SRTP/SRTCP 665 AES-CCM is another family of AEAD algorithms built around the AES 666 block cipher algorithm. AES-CCM uses AES counter mode for encryption 667 and AES Cipher Block Chaining Message Authentication Code (CBC MAC) 668 for authentication. A detailed description of the AES-CCM family can 669 be found in [RFC5116]. The following members of the AES-CCM family 670 may be used with SRTP/SRTCP: 672 Table 2: AES-CCM algorithms for SRTP/SRTCP 673 Name Key Size Auth. Tag Size Reference 674 ================================================================ 675 AEAD_AES_128_CCM 16 octets 8, 12 or 16 octets [RFC5116] 676 AEAD_AES_256_CCM 32 octets 8, 12 or 16 octets [RFC5116] 678 Any implementation of AES-CCM SRTP/SRTCP SHOULD support both 679 AEAD_AES_128_CCM and AEAD_AES_256_CCM. 681 AES-CCM uses a flag octet that conveys information about the length 682 of the authentication tag, length of the block counter, and presence 683 of additional authenticated data. For AES-CCM in SRTP/SRTCP, the 684 flag octet has the hex value 5A if an 8-octet authentication tag is 685 used, 6A if a 12-octet authentication tag is used, and 7A if a 686 16-octet authentication tag is used. The flag octet is one of the 687 inputs to AES during the counter mode encryption of the plaintext. 689 11. Key Derivation Functions 691 A Key Derivation Function (KDF) is used to derive all of the required 692 encryption and authentication keys from a secret value shared by the 693 endpoints. Both the AEAD_AES_128_GCM algorithms and the 694 AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key 695 Derivation Function described in [RFC3711]. Both the 696 AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST 697 use the AES_256_CM_PRF Key Derivation Function described in [RFC 698 6188]. 700 12. Security Considerations 702 12.1. Handling of Security Critical Parameters 704 As with any security process, the implementer must take care to 705 ensure cryptographically sensitive parameters are properly handled. 706 Many of these recommendations hold for all SRTP cryptographic 707 algorithms, but we include them here to emphasize their importance. 709 - If the master salt is to be kept secret, it MUST be properly 710 erased when no longer needed. 711 - The secret master key and all keys derived from it MUST be kept 712 secret. All keys MUST be properly erased when no longer 713 needed. 714 - At the start of each packet, the block counter MUST be reset (to 715 0 for CCM, to 1 for GCM). The block counter is incremented 716 after each block key has been produced, but it MUST NOT be 717 allowed to exceed 2^32-1. 718 - Each time a rekey occurs, the initial values of the SRTCP index 719 and the values of all the SEQ counters MUST be saved. 720 - Processing MUST cease if the 48-bit Packet Counter or the 31-bit 721 SRTCP index cycles back to its initial value. Processing MUST 722 NOT resume until a new SRTP/SRTCP session has been established 723 using a new SRTP master key. Ideally, a rekey should be done 724 well before either of these counters cycle. 726 12.2. Size of the Authentication Tag 728 We require that the AEAD authentication tag must be at least 8 729 octets, significantly reducing the probability of an adversary 730 successfully introducing fraudulent data. The goal of an 731 authentication tag is to minimize the probability of a successful 732 forgery occurring anywhere in the network we are attempting to 733 defend. There are three relevant factors: how low we wish the 734 probability of successful forgery to be (prob_success), how many 735 attempts the adversary can make (N_tries) and the size of the 736 authentication tag in bits (N_tag_bits). Then 738 prob_success < expected number of successes 739 = N_tries * 2^-N_tag_bits. 740 Suppose an adversary wishes to introduce a forged or altered packet 741 into a target network by randomly selecting an authentication value 742 until by chance they hit a valid authentication tag. The table below 743 summarizes the relationship between the number of forged packets the 744 adversary has tried, the size of the authentication tag, and the 745 probability of a compromise occurring (i.e. at least one of the 746 attempted forgeries having a valid authentication tag). The reader 747 is reminded that the forgery attempts can be made over the entire 748 network, not just a single link, and that frequently changing the key 749 does not decrease the probability of a compromise occurring. 751 +==================+========================================+ 752 | Authentication | Probability of a Compromise Occurring | 753 | Tag | for a given number of forgery attempts | 754 | Size |------------+-------------+-------------| 755 | (octets) | prob=2^-30 | prob=2^-20 | prob=2^-10 | 756 |==================+=============+=============+============| 757 | 4 | 2^2 tries | 2^12 tries | 2^22 tries | 758 |==================+============+=============+=============| 759 | 8 | 2^34 tries | 2^44 tries | 2^54 tries | 760 |==================+============+=============+=============| 761 | 12 | 2^66 tries | 2^76 tries | 2^86 tries | 762 |==================+============+=============+=============| 763 | 16 | 2^98 tries | 2^108 tries | 2^118 tries | 764 +=================+============+=============+==============+ 766 Table 3: Probability of a compromise occurring for a given 767 number of forgery attempts and tag size. 769 13. IANA Considerations 771 13.1. SDES 773 Security description [RFC 4568] defines SRTP "crypto suites"; a 774 crypto suite corresponds to a particular AEAD algorithm in SRTP. In 775 order to allow SDP to signal the use of the algorithms defined in 776 this document, IANA will register the following crypto suites into 777 the subregistry for SRTP crypto suites under the SRTP transport of 778 the SDP Security Descriptions: 780 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 781 "AEAD_AES_256_GCM" / 782 "AEAD_AES_128_GCM_8" / 783 "AEAD_AES_256_GCM_8" / 784 "AEAD_AES_128_GCM_12" / 785 "AEAD_AES_256_GCM_12" / 786 "AEAD_AES_128_CCM" / 787 "AEAD_AES_256_CCM" / 788 srtp-crypto-suite-ext 790 13.2. DTLS 792 DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; it 793 also corresponds to the use of an AEAD algorithm in SRTP. In order 794 to allow the use of the algorithms defined in this document in 795 DTLS-SRTP, we request IANA register the following SRTP Protection 796 Profiles: 798 AEAD_AES_128_CCM 799 cipher: AES_128_CCM 800 cipher_key_length: 128 bits 801 cipher_salt_length: 96 bits 802 maximum lifetime: at most 2^31 SRTCP packets and 803 at most 2^48 SRTP packets 805 AEAD_AES_256_CCM 806 cipher: AES_256_CCM 807 cipher_key_length: 256 bits 808 cipher_salt_length: 96 bits 809 maximum lifetime: at most 2^31 SRTCP packets and 810 at most 2^48 SRTP packets 812 AEAD_AES_128_CCM_8 813 cipher: AES_128_CCM 814 cipher_key_length: 128 bits 815 cipher_salt_length: 96 bits 816 maximum lifetime: at most 2^31 SRTCP packets and 817 at most 2^48 SRTP packets 819 AEAD_AES_256_CCM_8 820 cipher: AES_256_CCM 821 cipher_key_length: 256 bits 822 cipher_salt_length: 96 bits 823 maximum lifetime: at most 2^31 SRTCP packets and 824 at most 2^48 SRTP packets 826 AEAD_AES_128_CCM_12 827 cipher: AES_128_CCM 828 cipher_key_length: 128 bits 829 cipher_salt_length: 96 bits 830 maximum lifetime: at most 2^31 SRTCP packets and 831 at most 2^48 SRTP packets 833 AEAD_AES_256_CCM_12 834 cipher: AES_256_CCM 835 cipher_key_length: 256 bits 836 cipher_salt_length: 96 bits 837 maximum lifetime: at most 2^31 SRTCP packets and 838 at most 2^48 SRTP packets 840 AEAD_AES_128_CCM 841 cipher: AES_128_CCM 842 cipher_key_length: 128 bits 843 cipher_salt_length: 96 bits 844 maximum lifetime: at most 2^31 SRTCP packets and 845 at most 2^48 SRTP packets 847 AEAD_AES_256_CCM 848 cipher: AES_256_CCM 849 cipher_key_length: 256 bits 850 cipher_salt_length: 96 bits 851 maximum lifetime: at most 2^31 SRTCP packets and 852 at most 2^48 SRTP packets 854 AEAD_AES_128_GCM_8 855 cipher: AES_128_GCM 856 cipher_key_length: 128 bits 857 cipher_salt_length: 96 bits 858 maximum lifetime: at most 2^31 SRTCP packets and 859 at most 2^48 SRTP packets 861 AEAD_AES_256_GCM_8 862 cipher: AES_256_GCM 863 cipher_key_length: 256 bits 864 cipher_salt_length: 96 bits 865 maximum lifetime: at most 2^31 SRTCP packets and 866 at most 2^48 SRTP packets 868 AEAD_AES_128_GCM_12 869 cipher: AES_128_GCM 870 cipher_key_length: 128 bits 871 cipher_salt_length: 96 bits 872 maximum lifetime: at most 2^31 SRTCP packets and 873 at most 2^48 SRTP packets 875 AEAD_AES_256_GCM_12 876 cipher: AES_256_GCM 877 cipher_key_length: 256 bits 878 cipher_salt_length: 96 bits 879 maximum lifetime: at most 2^31 SRTCP packets and 880 at most 2^48 SRTP packets 882 Note that these SRTP Protection Profiles do not specify an 883 auth_function, auth_key_length, or auth_tag_length because all of 884 these profiles use AEAD algorithms, and thus do not use a separate 885 auth_function, auth_key, or auth_tag. 887 13.3. MIKEY 889 In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], 890 IANA maintains several Payload Name Spaces under Multimedia Internet 891 KEYing (MIKEY). This document requires dditions to two of the lists 892 maintained under MIKEY Security Protocol Parameters. 894 On the SRTP policy Type/Value list (derived from Table 6.10.1.a of 895 [RFC3830]) we request the following addition: 897 Type | Meaning | Possible values 898 ---------------------------------------------------------------- 899 TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) 901 On the Encryption Algorithm List (derived from Table 6.10.1.b of 902 [RFC3830]) we request the following additions: 904 SRTP encr alg. | Value | Default Session Encr. Key Length 905 ----------------------------------------------------------- 906 AES-CCM | TBD | 16 octets 907 AES-GCM | TBD | 16 octets 909 The SRTP encryption algorithm, session encryption key length, and 910 AEAD authentication tag values received from MIKEY fully determine 911 the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is 912 described in section 14. 914 14. Parameters for use with MIKEY 916 MIKEY specifies the algorithm family separately from the key length 917 (which is specified by the Session Encryption key length ) and the 918 authentication tag length (specified by AEAD Auth. tag length). 920 +------------+-------------+---------------+ 921 | Encryption | Encryption | AEAD Auth. | 922 | Algorithm | Key Length | Tag Length | 923 +============+=============+===============+ 924 AEAD_AES_128_GCM | AES-GCM | 16 | 16 | 925 +------------+-------------+---------------+ 926 AEAD_AES_128_CCM | AES-CCM | 16 | 16 | 927 +------------+-------------+---------------+ 928 AEAD_AES_128_GCM_12 | AES-GCM | 16 | 12 | 929 +------------+-------------+---------------+ 930 AEAD_AES_128_CCM_12 | AES-CCM | 16 | 12 | 931 +------------+-------------+---------------+ 932 AEAD_AES_128_GCM_8 | AES-GCM | 16 | 8 | 933 +------------+-------------+---------------+ 934 AEAD_AES_128_CCM_8 | AES-CCM | 16 | 8 | 935 +------------+-------------+---------------+ 936 AEAD_AES_256_GCM | AES-GCM | 32 | 16 | 937 +------------+-------------+---------------+ 938 AEAD_AES_256_CCM | AES-CCM | 16 | 16 | 939 +------------+-------------+---------------+ 940 AEAD_AES_256_GCM_12 | AES-GCM | 32 | 12 | 941 +------------+-------------+---------------+ 942 AEAD_AES_256_CCM_12 | AES-CCM | 16 | 12 | 943 +------------+-------------+---------------+ 944 AEAD_AES_256_GCM_8 | AES-GCM | 32 | 8 | 945 +------------+-------------+---------------+ 946 AEAD_AES_256_CCM_8 | AES-CCM | 16 | 8 | 947 +============+=============+===============+ 949 Table 4: Mapping MIKEY parameters to AEAD algorithm 951 Section 11 in this document restricts the choice of Key Derivation 952 Function for AEAD algorithms. To enforce this restriction in MIKEY, 953 we require that the SRTP PRF has value AES-CM whenever an AEAD 954 algorithm is used. Note that, according to Section 6.10.1 in 955 [RFC3830], the key length of the Key Derivation Function (i.e. the 956 SRTP master key length) is always equal to the session encryption key 957 length. This means, for example, that AEAD_AES_256_GCM will use 958 AES_256_CM_PRF as the Key Derivation Function. 960 15. Acknowledgements 962 The authors would like to thank Michael Peck, Michael Torla, Qin Wu, 963 Magnus Westerland, Oscar Ohllson and many other reviewers who 964 provided valuable comments on earlier drafts of this document. 966 16. References 968 16.1. Normative References 970 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 971 Mode for Authentication and Confidentiality", U.S. 972 National Institute of Standards and Technology http:// 973 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 975 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 976 Recommendation for Block Cipher Modes of Operation: 977 Galois/Counter Mode (GCM) and GMAC.", U.S. National 978 Institute of Standards and Technology http:// 979 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 981 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 982 Requirement Levels", BCP 14, RFC 2119, March 1997. 984 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 985 K. Norrman, "The Secure Real-time Transport Protocol 986 (SRTP)", RFC 3711, March 2004. 988 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and 989 Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830, 990 August 2004. 992 [RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session 993 Description Protocol (SDP): Security Descriptions for 994 Media Streams", RFC 4568, July 2006. 996 [RFC5116] McGrew, D., "An Interface and Algorithms for 997 Authenticated Encryption with Associated Data", RFC 5116, 998 January 2008. 1000 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 1001 Algorithms with the Encrypted Payload of the Internet Key 1002 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. 1004 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1005 Security (DTLS) Extension to Establish Keys for the Secure 1006 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1008 [RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP" 1009 RFC 6811, March 2011 1011 16.2. Informative References 1013 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 1014 Relations among notions and analysis of the generic 1015 composition paradigm", Proceedings of ASIACRYPT 2000, 1016 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 1017 www-cse.ucsd.edu/users/mihir/papers/oem.html. 1019 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication 1020 and Key Establishment", Springer, 2003 . 1022 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 1023 CryptoToolkit/modes/800-38_Series_Publications/ 1024 SP800-38B.pdf. 1026 [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and 1027 provably repairing the SSH authenticated encryption 1028 scheme: A case study of the Encode-then-Encrypt-and-MAC 1029 paradigm", ACM Transactions on Information and System Secu 1030 rity, http://www-cse.ucsd.edu/users/tkohno/papers/ 1031 TISSEC04/. 1033 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 1034 than Real: Security Challenges in Virtual Machine Based 1035 Computing Environments", Proceedings of the 10th Workshop 1036 on Hot Topics in Operating Systems http:// 1037 www.stanford.edu/~talg/papers/HOTOS05/ 1038 virtual-harder-hotos05.pdf. 1040 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", 1041 Proceedings of the 9th Annual Workshop on Selected Areas 1042 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/ 1043 proposedmodes/ccm/ccm-ad1.pdf, 2002. 1045 [MODES] Dworkin, M., "NIST Special Publication 800-38: 1046 Recommendation for Block Cipher Modes of Operation", U.S. 1047 National Institute of Standards and Technology http:// 1048 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 1050 [MV04] McGrew, D. and J. Viega, "The Security and Performance of 1051 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT 1052 '04, http://eprint.iacr.org/2004/193, December 2004. 1054 [R02] Rogaway, P., "Authenticated encryption with Associated- 1055 Data", ACM Conference on Computer and Communication 1056 Security (CCS'02), pp. 98-107, ACM Press, 1057 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 1059 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1060 Hashing for Message Authentication", RFC 2104, 1061 February 1997. 1063 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1064 Requirements for Security", BCP 106, RFC 4086, June 2005. 1066 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1067 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1068 RFC 4106, June 2005. 1070 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1071 Key Management", BCP 107, RFC 4107, June 2005. 1073 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1074 RFC 4303, December 2005. 1076 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1077 Mode with IPsec Encapsulating Security Payload (ESP)", 1078 RFC 4309, December 2005. 1080 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1081 Transform Carrying Roll-Over Counter for the Secure Real- 1082 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1084 Author's Address 1086 David A. McGrew 1087 Cisco Systems, Inc. 1088 510 McCarthy Blvd. 1089 Milpitas, CA 95035 1090 US 1091 Phone: (408) 525 8651 1092 Email: mcgrew@cisco.com 1093 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1095 Kevin M. Igoe 1096 NSA/CSS Commercial Solutions Center 1097 National Security Agency 1098 EMail: kmigoe@nsa.gov 1100 Acknowledgement 1102 Funding for the RFC Editor function is provided by the IETF 1103 Administrative Support Activity (IASA).