idnits 2.17.1 draft-ietf-avtcore-srtp-aes-gcm-02.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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 5 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 (August 15, 2012) is 4272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4568' is mentioned on line 841, but not defined == Unused Reference: 'CCM' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC4568' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC6188' is defined on line 1085, but no explicit reference was found in the text == Unused Reference: 'BOYD' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'CMAC' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: 'EEM04' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: 'GR05' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'J02' is defined on line 1120, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'MV04' is defined on line 1130, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 1143, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1156, 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: February 16, 2013 National Security Agency 6 August 15, 2012 8 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) 9 draft-ietf-avtcore-srtp-aes-gcm-02 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 February 16, 2013. 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 and AES-CCM Authenticated 46 Encryption with Associated Data algorithms can be used to provide 47 confidentiality and data authentication in the SRTP protocol. 49 Table of Contents 51 1. Introduction.....................................................3 52 2. Conventions Used In This Document................................3 53 3. Overview of the SRTP/SRTCP Security Architecture.................4 54 4. Terminology......................................................4 55 5. Generic AEAD Processing..........................................5 56 5.1. Types of Input Data.........................................5 57 5.2. AEAD Invocation Inputs and Outputs..........................5 58 5.2.1. Encrypt Mode...........................................5 59 5.2.2. Decrypt Mode...........................................6 60 5.3. Handling of AEAD Authentication.............................6 61 6. Counter Mode Encryption..........................................6 62 7. AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12......................7 63 8. Unneeded SRTP/SRTCP Fields.......................................8 64 8.1. SRTP/SRTCP Authentication Field.............................8 65 8.2. RTP Padding.................................................8 66 9. AES-GCM/CCM processing for SRTP..................................8 67 9.1. SRTP IV formation for AES-GCM and AES-CCM...................8 68 9.2. Data Types in SRTP Packets..................................9 69 9.3. Prevention of SRTP IV Reuse................................10 70 10. AES-GCM/CCM Processing of SRTCP Compound Packets...............11 71 10.1. SRTCP IV formation for AES-GCM and AES-CCM................11 72 10.2. Data Types in Encrypted SRTCP Compound Packets............12 73 10.3. Data Types in Unencrypted SRTCP Compound Packets..........13 74 10.4. Prevention of SRTCP IV Reuse..............................14 75 11. Constraints on AEAD for SRTP and SRTCP.........................14 76 11.1. Generic AEAD Parameter Constraints........................15 77 11.2. AES-GCM for SRTP/SRTCP....................................15 78 11.3. AES-CCM for SRTP/SRTCP....................................16 79 12. Key Derivation Functions.......................................16 80 13. Security Considerations........................................17 81 13.1. Handling of Security Critical Parameters..................17 82 13.2. Size of the Authentication Tag............................17 83 14. IANA Considerations............................................18 84 14.1. SDES......................................................18 85 14.2. DTLS......................................................19 86 14.3. MIKEY.....................................................20 87 14.4. AEAD registry.............................................21 88 15. Parameters for use with MIKEY..................................21 89 16. Acknowledgements...............................................22 90 17. References.....................................................23 91 17.1. Normative References......................................23 92 17.2. Informative References....................................24 94 1. Introduction 96 The Secure Real-time Transport Protocol (SRTP) is a profile of the 97 Real-time Transport Protocol (RTP), which can provide 98 confidentiality, message authentication, and replay protection to the 99 RTP traffic and to the control traffic for RTP, the Real-time 100 Transport Control Protocol (RTCP). It is important to note that the 101 outgoing SRTP packets from a single endpoint may be originating from 102 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) and AES Counter with Cipher Block Chaining-Message 117 Authentication Code (AES-CCM), are based upon AES. This 118 specification makes use of the AES versions that use 128-bit and 119 256-bit keys, which we call AES-128 and AES-256, respectively. 121 The Galois/Counter Mode of operation (GCM) and the Counter with 122 Cipher Block Chaining-Message Authentication Code mode of operation 123 (CCM) are both AEAD modes of operation for block ciphers. Both use 124 counter mode to encrypt the data, an operation that can be 125 efficiently pipelined. Further, GCM authentication uses operations 126 that are particularly well suited to efficient implementation in 127 hardware, making it especially appealing for high-speed 128 implementations, or for implementations in an efficient and compact 129 circuit. CCM is well suited for use in compact software 130 implementations. This specification uses GCM and CCM with both 131 AES-128 and AES-256. 133 In summary, this document defines how to use AEAD algorithms, 134 particularly AES-GCM and AES-CCM, to provide confidentiality and 135 message authentication within SRTP and SRTCP packets. 137 2. Conventions Used In This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Overview of the SRTP/SRTCP Security Architecture 145 SRTP/SRTCP security is based upon the following principles: 147 a) Both privacy and authentication are based upon the use of 148 symmetric algorithms. An AEAD algorithm such as AES-CCM or 149 AES-GCM combines privacy and authentication into a single 150 process. 152 b) A secret master key is shared by all participating endpoints, 153 both those originating SRTP/SRTCP packets and those receiving 154 these packets. Any given master key MAY be used 155 simultaneously by several endpoints to originate SRTP/SRTCP 156 packets (as well one or more endpoints using this master key 157 to process inbound data). 159 c) A Key Derivation Function is applied to the shared master key 160 value to form separate encryption keys, authentication keys 161 and salting keys for SRTP and for SRTCP (a total of six 162 keys). This process is described in sections 4.3.1 and 4.3.3 163 of [RFC3711]. Since AEAD algorithms such as AES-CCM and 164 AES-GCM combine encryption and authentication into a single 165 process, AEAD algorithms do not make use of the 166 authentication keys. The master key MUST be at least as 167 large as the encryption key derived from it. 169 4. Terminology 171 The following terms have very specific meanings in the context of 172 this RFC: 174 Crypto Context For the purposes of this document, a crypto 175 context is the outcome of any process which 176 results in authentication of each endpoint in the 177 SRTP session and possession by each endpoint of a 178 shared secret master key. Various encryption 179 keys, authentication keys and salts are derived 180 from the master key. Aside from making 181 modifications to IANA registries to allow AES-GCM 182 and AES-CCM to work with SDES, DTLS and MIKEY, the 183 details of how the master key is established are 184 outside the scope of this document. Similarly any 185 mechanism for rekeying an existing Cipher Context 186 is outside the scope of the document. 188 Instantiation In AEAD, an instantiation is an (Encryption_key, 189 salt) pair together with all of the data 190 structures (for example, counters) needed for it 191 to function properly. In SRTP/SRTCP, each 192 endpoint will need two instantiations of the AEAD 193 algorithm for each master key in its possession, 194 one for SRTP and one for SRTCP. 196 Invocation SRTP/SRTCP data streams are broken into packets. 197 Each packet is processed by a single invocation of 198 the appropriate instantiation of the AEAD 199 algorithm. 201 In many applications, each endpoint will have one master key for 202 processing outbound data but may have one or more separate master 203 keys for processing inbound data. 205 5. Generic AEAD Processing 207 5.1. Types of Input Data 209 Associated Data This is data that is to be authenticated but 210 not encrypted. 212 Plaintext Data that is to be both encrypted and 213 authenticated. 215 Raw Data Data that is to be neither encrypted nor 216 authenticated. 218 Which portions of SRTP/SRTCP packets that are to be treated as 219 associated data, which are to be treated as plaintext, and which are 220 to be treated as raw data are covered in sections 9.2, 10.2 and 221 10.3. 223 5.2. AEAD Invocation Inputs and Outputs 225 5.2.1. Encrypt Mode 227 Inputs: 228 Encryption_key Octet string, either 16 or 32 229 octets long 230 Initialization_Vector Octet string, 12 octets long 231 Associated_Data Bit string of variable length 232 Plaintext Bit string of variable length 233 Tag_Size_Flag (CCM only*) One Octet 235 Outputs 236 Ciphertext Bit string, length = 237 length(plaintext)+tag_length 239 (*) For GCM, the algorithm choice determines the tag size. 241 AES-CCM uses a Tag_Size_Flag that has the hex value 5A if an 8-octet 242 authentication tag is used, 6A if a 12-octet authentication tag is 243 used, and 7A if a 16-octet authentication tag is used. 245 5.2.2. Decrypt Mode 247 Inputs: 248 Encryption_key Octet string, either 16 or 32 249 Octets long 250 Initialization_Vector Octet string, 12 octets long 251 Associated_Data Octet string of variable length 252 Ciphertext Octet string of variable length 253 Tag_Size_Flag (CCM only*) One octet 255 Outputs 256 Plaintext Bit string, length = 257 length(ciphertext)-tag_length 258 Validity_Flag Boolean, TRUE if valid, 259 FALSE otherwise 261 (*) For GCM, the algorithm choice determines the tag size. 263 The Tag_Size_Flag used in AES-CCM has the hex value 5A if an 8-octet 264 authentication tag is used, 6A if a 12-octet authentication tag is 265 used, and 7A if a 16-octet authentication tag is used. 267 5.3. Handling of AEAD Authentication 269 AEAD requires that all incoming packets MUST pass AEAD authentication 270 before any other action takes place. Plaintext and associated data 271 MUST NOT be released until the AEAD authentication tag has been 272 validated. Further, when GCM is being used, the ciphertext MUST NOT 273 be decrypted until the AEAD tag has been validated. 275 Should the AEAD tag prove to be invalid, the packet in question is to 276 be discarded and a Validation Error flag raised. Local policy 277 determines how this flag is to be handled and is outside the scope of 278 this document. 280 6. Counter Mode Encryption 282 Each outbound packet uses a 12 octet IV and encryption key to form a 283 keystream of bits which is XORed to the plaintext to form cipher. 284 When GCM is used, the concatenation of a 12-octet IV, with a 4-octet 285 block counter forms the input to AES. This is used to build a 286 key_stream as follows: 288 def GCM_keystream( plaintext, IV, Encryption_key ): 289 assert len(plaintext) <= (2**36 - 32) 290 key_stream = "" 291 block_counter = 1 292 while len(key_stream) < len(plaintext): 293 key_block = AES_ENC( data=IV||block_counter, 294 key=Encryption_key ) 295 key_stream = key_stream || key_block 296 block_counter = block_counter + 1 297 key_stream = truncate( key_stream, len(plaintext) ) 298 last_key_block = AES_ENC( data=IV||block_counter, 299 key=Encryption_key ) 300 return (key_stream, last_key_block ) 302 The last_key_block is reserved to form the GMAC of the message by 303 encrypting the GHASH of the message. It is not required for CCM. 305 When CCM is used, the AES input is the concatenation of a 12-octet 306 IV, a 1-octet Tag_Size_Flag, and a 4-octet block counter. A 307 keystream is formed as follows: 309 def CCM_keystream( plaintext, IV, Tag_Size_Flag, Encryption_key ): 310 assert len(plaintext) <= 2**28 311 key_stream = "" 312 block_counter = 0 313 while len(key_stream)(+) 396 +--+--+--+--+--+--+--+--+--+--+--+--+ | 397 | 398 +--+--+--+--+--+--+--+--+--+--+--+--+ | 399 | Initialization Vector |<--+ 400 +--+--+--+--+--+--+--+--+--+--+--+--+ 402 Figure 1: AES-GCM and AES-CCM SRTP 403 Initialization Vector formation. 405 Using the terminology of section 8.2.1. of [GCM], the first six 406 octets of the IV are the fixed field and the last six octets are the 407 invocation field. 409 9.2. Data Types in SRTP Packets 411 All SRTP packets MUST be both authenticated and encrypted. The data 412 fields within the SRTP packets are broken into Associated Data, 413 Plaintext and Raw Data as follows (see figure 2): 415 Associated Data The version (2 bits), padding flag (1 bit), 416 extension flag (1 bit), CSRC count (4 bits), 417 sequence number (16 bits), timestamp (32 bits), 418 SSRC (32 bits), optional contributing source 419 identifiers (CSRCs, 32 bits each), and optional 420 RTP extension (variable length). 422 Plaintext The RTP payload (variable length), RTP padding (if 423 used, variable length), and RTP pad count ( if 424 used, 1 octet). 426 Raw Data The optional 32-bit SRTP MKI and the 32-bit SRTP 427 authentication tag (whose use is NOT 428 RECOMMENDED). 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 A |V=2|P|X| CC |M| Packet Type | sequence number | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 A | timestamp | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 A | synchronization source (SSRC) identifier | 438 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 439 A | contributing source (CSRC) identifiers (optional) | 440 A | .... | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 A | RTP extension (OPTIONAL) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 P | payload ... | 445 P | +-------------------------------+ 446 P | | RTP padding | RTP pad count | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 R : SRTP MKI (optional) : 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 R : authentication tag (NOT RECOMMENDED) : 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 P = Plaintext (to be encrypted and authenticated) 454 A = Associated Data (to be authenticated only) 455 R = neither encrypted nor authenticated 457 Note: The RTP padding and RTP padding count fields are optional 458 and are not recommended 460 Figure 2: AEAD inputs from an SRTP packet 462 Since the AEAD cipher is larger that the plaintext by exactly the 463 length of the AEAD authentication tag, the corresponding SRTP 464 encrypted packet replaces the plaintext field by a slightly larger 465 field containing the cipher. Even if the plaintext field is empty, 466 AEAD encryption must still be performed, with the resulting cipher 467 consisting solely of the authentication tag. This tag is to be 468 placed immediately before the optional SRTP MKI and SRTP 469 authentication tag fields. 471 9.3. Prevention of SRTP IV Reuse 473 In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC) 474 triple is never used twice with the same master key. There are two 475 phases to this issue. 477 Counter Management A rekey MUST be performed to establish a new 478 master key before the (ROC,SEQ) pair cycles back 479 to its original value. 481 SSRC Management The set of all SSRC values must be partitioned 482 into disjoint pools, one pool for each endpoint 483 using the master key to originate outbound 484 data. Each such endpoint MUST only issue SSRC 485 values from the pool it has been assigned. 486 Further, each endpoint MUST maintain a history 487 of outbound SSRC identifiers that it has issued 488 within the lifetime of the current master key, 489 and when a new synchronization source requests 490 an SSRC identifier it MUST NOT be given an 491 identifier that has been previously issued. A 492 rekey MUST be performed before its pool of SSRC 493 values is exhausted. 495 10. AES-GCM/CCM Processing of SRTCP Compound Packets 497 All SRTCP compound packets MUST be authenticated, but unlike SRTP, 498 SRTCP packet encryption is optional. A sender can select which 499 packets to encrypt, and indicates this choice with a 1-bit encryption 500 flag (located just before the 31-bit SRTCP index) 502 10.1. SRTCP IV formation for AES-GCM and AES-CCM 504 The 12 octet initialization vector used by both AES-GCM and AES-CCM 505 SRTCP is formed by first concatenating 2-octets of zeroes, the 506 4-octet Synchronization Source identifier (SSRC), 2-octets of zeroes, 507 a single zero bit, and the 31-bit SRTCP Index. The resulting 508 12-octet value is then XORed to the 12-octet salt to form the 509 12-octet IV. 511 0 1 2 3 4 5 6 7 8 9 10 11 512 +--+--+--+--+--+--+--+--+--+--+--+--+ 513 |00|00| SSRC |00|00|0+SRTCP Idx|---+ 514 +--+--+--+--+--+--+--+--+--+--+--+--+ | 515 | 516 +--+--+--+--+--+--+--+--+--+--+--+--+ | 517 | Encryption Salt |->(+) 518 +--+--+--+--+--+--+--+--+--+--+--+--+ | 519 | 520 +--+--+--+--+--+--+--+--+--+--+--+--+ | 521 | Initialization Vector |<--+ 522 +--+--+--+--+--+--+--+--+--+--+--+--+ 524 Figure 3: SRTCP Initialization Vector formation 526 Using the terminology of section 8.2.1. of [GCM], the first eight 527 octets of the IV are the fixed field and the last four octets are the 528 invocation field. 530 10.2. Data Types in Encrypted SRTCP Compound Packets 532 When the encryption flag is set to 1, the SRTCP packet is broken into 533 plaintext, associated data, and raw (untouched) data as listed below 534 (see figure 4): 536 Associated Data The packet version (2 bits), padding flag (1 bit), 537 reception report count (5 bits), packet type (8 538 bits), length (2 octets), SSRC (4 octets), 539 encryption flag (1 bit) and SRTCP index (31 540 bits). 542 Raw Data The 32-bit optional SRTCP MKI index and 32-bit 543 SRTCP authentication tag (whose use is NOT 544 RECOMMENDED). 546 Plaintext All other data. 548 Note that the plaintext comes in one contiguous field. Since the 549 AEAD cipher is larger than the plaintext by exactly the length of the 550 AEAD authentication tag, the corresponding SRTCP encrypted packet 551 replaces the plaintext field with a slightly larger field containing 552 the cipher. Even if the plaintext field is empty, AEAD encryption 553 must still be performed, with the resulting cipher consisting solely 554 of the authentication tag. This tag is to be placed immediately 555 before the encryption flag and SRTCP index. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 A |V=2|P| RC | Packet Type | length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 A | synchronization source (SSRC) of Sender | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 P | sender info | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 P | report block 1 | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 P | report block 2 | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 P | ... | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 P |V=2|P| SC | Packet Type | length | 573 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 574 P | SSRC/CSRC_1 | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 P | SDES items | 577 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 578 P | ... | 579 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 580 A |1| SRTCP index | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 R | SRTCP MKI (optional) index | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 R : authentication tag (NOT RECOMMENDED) : 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 P = Plaintext (to be encrypted and authenticated) 588 A = Associated Data (to be authenticated only) 589 R = neither encrypted nor authenticated 591 Figure 4: AEAD SRTCP inputs when encryption flag = 1. 593 10.3. Data Types in Unencrypted SRTCP Compound Packets 595 When the encryption flag is set to 0, the SRTCP compound packet is 596 broken into plaintext, associated data, and raw (untouched) data as 597 follows (see figure 5): 599 Plaintext None. 601 Raw Data The 32-bit optional SRTCP MKI index and 32-bit 602 SRTCP authentication tag (whose use is NOT 603 RECOMMENDED). 605 Associated Data All other data. 607 Even though there is no plaintext in this RTCP packet, AEAD 608 encryption returns a cipher field which is precisely the length of 609 the AEAD authentication tag. This cipher is to be placed before the 610 Encryption flag and the SRTCP index in the authenticated SRTCP 611 packet. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 A |V=2|P| RC | Packet Type | length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 A | synchronization source (SSRC) of Sender | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 A | sender info | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 A | report block 1 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 A | report block 2 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 A | ... | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 A |V=2|P| SC | Packet Type | length | 629 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 630 A | SSRC/CSRC_1 | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 A | SDES items | 633 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 634 A | ... | 635 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 636 A |0| SRTCP index | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 R | SRTCP MKI (optional)index | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 R : authentication tag (NOT RECOMMENDED) : 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 A = Associated Data (to be authenticated only) 644 R = neither encrypted nor authenticated 646 Figure 5: AEAD SRTCP inputs when encryption flag = 0 648 10.4. Prevention of SRTCP IV Reuse 650 A new master key MUST be established before the 31-bit SRTCP index 651 cycles back to its original value. Ideally, a rekey performed should 652 be performed and a new master key put in place well before the SRTCP 653 index overflows. 655 The comments on SSRC management in section 9.3 also apply. 657 11. Constraints on AEAD for SRTP and SRTCP 659 In general, any AEAD algorithm can accept inputs with varying 660 lengths, but each algorithm can accept only a limited range of 661 lengths for a specific parameter. In this section, we describe the 662 constraints on the parameter lengths that any AEAD algorithm must 663 support to be used in AEAD-SRTP. Additionally, we specify a complete 664 parameter set for two specific AEAD algorithms, namely AES-GCM and 665 AES-CCM. 667 11.1. Generic AEAD Parameter Constraints 669 All AEAD algorithms used with SRTP/SRTCP MUST satisfy the three 670 constraints listed below: 672 PARAMETER Meaning Value 674 A_MAX maximum additional MUST be at least 12 octets 675 authenticated data 676 length 677 N_MIN minimum nonce (IV) MUST be no more than 12 octets 678 length 679 N_MAX maximum nonce (IV) MUST be at least 12 octets 680 length 681 C_MAX maximum ciphertext GCM: MUST be at most 2^36-16 octets 682 length per invocation CCM: MUST be at most 2^24+16 octets 683 C_MAX values less than 2232 684 are discouraged 686 The upper bound on C_MAX are based on purely cryptographic 687 considerations. The lower bound on C_MAX is obtained by subtracting 688 away a 20-octet IP header, 8-octet UDP header, and 12-octet RTP 689 header from the maximum transmission unit (MTU) of 2272. 691 For sake of clarity we specify two additional parameters: 693 Authentication Tag Length MUST be either 8, 12, or 16 694 octets 695 Maximum number of invocations MUST be at most 2^48 for SRTP 696 for a given instantiation MUST be at most 2^31 for SRTCP 697 Block Counter size MUST be 24 bits for CCM, 698 MUST be 32 bits for GCM 700 The reader is reminded that the ciphertext is longer than the 701 plaintext by exactly the length of the AEAD authentication tag. 703 11.2. AES-GCM for SRTP/SRTCP 705 AES-GCM is a family of AEAD algorithms built around the AES block 706 cipher algorithm. AES-GCM uses AES counter mode for encryption and 707 Galois Message Authentication Code (GMAC) for authentication. A 708 detailed description of the AES-GCM family can be found in 709 [RFC5116]. The following members of the AES-GCM family may be used 710 with SRTP/SRTCP: 712 Table 1: AES-GCM algorithms for SRTP/SRTCP 713 Name Key Size Auth. Tag Size Reference 714 ================================================================ 715 AEAD_AES_128_GCM 16 octets 16 octets [RFC5116] 716 AEAD_AES_256_GCM 32 octets 16 octets [RFC5116] 717 AEAD_AES_128_GCM_8 16 octets 8 octets [RFC5282] 718 AEAD_AES_256_GCM_8 32 octets 8 octets [RFC5282] 719 AEAD_AES_128_GCM_12 16 octets 12 octets [RFC5282] 720 AEAD_AES_256_GCM_12 32 octets 12 octets [RFC5282] 722 Any implementation of AES-GCM SRTP SHOULD support both 723 AEAD_AES_128_GCM_8 and AEAD_AES_256_GCM_8, and it MAY support the 724 four other variants shown in table 1. 726 11.3. AES-CCM for SRTP/SRTCP 728 AES-CCM is another family of AEAD algorithms built around the AES 729 block cipher algorithm. AES-CCM uses AES counter mode for encryption 730 and AES Cipher Block Chaining Message Authentication Code (CBC MAC) 731 for authentication. A detailed description of the AES-CCM family can 732 be found in [RFC5116]. Four of the six CCM algorithms used in this 733 document are defined in previous RFCs, while two, AEAD_AES_128_CCM_12 734 and AEAD_AES_256_CCM_12, are defined in section 7 of this document. 736 Table 2: AES-CCM algorithms for SRTP/SRTCP 737 Name Key Size Auth. Tag Size Reference 738 ================================================================ 739 AEAD_AES_128_CCM 128 bits 16 octets [RFC5116] 740 AEAD_AES_256_CCM 256 bits 16 octets [RFC5116] 741 AEAD_AES_128_CCM_12 128 bits 12 octets see section 7 742 AEAD_AES_256_CCM_12 256 bits 12 octets see section 7 743 AEAD_AES_128_CCM_8 128 bits 8 octets [RFC6655] 744 AEAD_AES_256_CCM_8 256 bits 8 octets [RFC6655] 746 Any implementation of AES-CCM SRTP/SRTCP SHOULD support both 747 AEAD_AES_128_CCM and AEAD_AES_256_CCM. 749 AES-CCM uses a flag octet that conveys information about the length 750 of the authentication tag, length of the block counter, and presence 751 of additional authenticated data. For AES-CCM in SRTP/SRTCP, the 752 flag octet has the hex value 5A if an 8-octet authentication tag is 753 used, 6A if a 12-octet authentication tag is used, and 7A if a 754 16-octet authentication tag is used. The flag octet is one of the 755 inputs to AES during the counter mode encryption of the plaintext. 757 12. Key Derivation Functions 759 A Key Derivation Function (KDF) is used to derive all of the required 760 encryption and authentication keys from a secret value shared by the 761 endpoints. Both the AEAD_AES_128_GCM algorithms and the 762 AEAD_AES_128_CCM algorithms MUST use the (128-bit) AES_CM_PRF Key 763 Derivation Function described in [RFC3711]. Both the 764 AEAD_AES_256_GCM algorithms and the AEAD_AES_256_CCM algorithms MUST 765 use the AES_256_CM_PRF Key Derivation Function described in [RFC 766 6188]. 768 13. Security Considerations 770 13.1. Handling of Security Critical Parameters 772 As with any security process, the implementer must take care to 773 ensure cryptographically sensitive parameters are properly handled. 774 Many of these recommendations hold for all SRTP cryptographic 775 algorithms, but we include them here to emphasize their importance. 777 - If the master salt is to be kept secret, it MUST be properly 778 erased when no longer needed. 779 - The secret master key and all keys derived from it MUST be kept 780 secret. All keys MUST be properly erased when no longer 781 needed. 782 - At the start of each packet, the block counter MUST be reset (to 783 0 for CCM, to 1 for GCM). The block counter is incremented 784 after each block key has been produced, but it MUST NOT be 785 allowed to exceed 2^32 for GCM and 2^24 for CCM. 786 - Each time a rekey occurs, the initial values of the SRTCP index 787 and the values of all the SEQ counters MUST be saved. 788 - Processing MUST cease if the 48-bit Packet Counter or the 31-bit 789 SRTCP index cycles back to its initial value. Processing MUST 790 NOT resume until a new SRTP/SRTCP session has been established 791 using a new SRTP master key. Ideally, a rekey should be done 792 well before either of these counters cycle. 794 13.2. Size of the Authentication Tag 796 We require that the AEAD authentication tag must be at least 8 797 octets, significantly reducing the probability of an adversary 798 successfully introducing fraudulent data. The goal of an 799 authentication tag is to minimize the probability of a successful 800 forgery occurring anywhere in the network we are attempting to 801 defend. There are three relevant factors: how low we wish the 802 probability of successful forgery to be (prob_success), how many 803 attempts the adversary can make (N_tries) and the size of the 804 authentication tag in bits (N_tag_bits). Then 806 prob_success < expected number of successes 807 = N_tries * 2^-N_tag_bits. 808 Suppose an adversary wishes to introduce a forged or altered packet 809 into a target network by randomly selecting an authentication value 810 until by chance they hit a valid authentication tag. The table below 811 summarizes the relationship between the number of forged packets the 812 adversary has tried, the size of the authentication tag, and the 813 probability of a compromise occurring (i.e. at least one of the 814 attempted forgeries having a valid authentication tag). The reader 815 is reminded that the forgery attempts can be made over the entire 816 network, not just a single link, and that frequently changing the key 817 does not decrease the probability of a compromise occurring. 819 +==================+========================================+ 820 | Authentication | Probability of a Compromise Occurring | 821 | Tag | for a given number of forgery attempts | 822 | Size |------------+-------------+-------------| 823 | (octets) | prob=2^-30 | prob=2^-20 | prob=2^-10 | 824 |==================+=============+=============+============| 825 | 4 | 2^2 tries | 2^12 tries | 2^22 tries | 826 |==================+============+=============+=============| 827 | 8 | 2^34 tries | 2^44 tries | 2^54 tries | 828 |==================+============+=============+=============| 829 | 12 | 2^66 tries | 2^76 tries | 2^86 tries | 830 |==================+============+=============+=============| 831 | 16 | 2^98 tries | 2^108 tries | 2^118 tries | 832 +=================+============+=============+==============+ 834 Table 3: Probability of a compromise occurring for a given 835 number of forgery attempts and tag size. 837 14. IANA Considerations 839 14.1. SDES 841 Security description [RFC 4568] defines SRTP "crypto suites"; a 842 crypto suite corresponds to a particular AEAD algorithm in SRTP. In 843 order to allow SDP to signal the use of the algorithms defined in 844 this document, IANA will register the following crypto suites into 845 the subregistry for SRTP crypto suites under the SRTP transport of 846 the SDP Security Descriptions: 848 srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / 849 "AEAD_AES_256_GCM" / 850 "AEAD_AES_128_GCM_8" / 851 "AEAD_AES_256_GCM_8" / 852 "AEAD_AES_128_GCM_12" / 853 "AEAD_AES_256_GCM_12" / 854 "AEAD_AES_128_CCM" / 855 "AEAD_AES_256_CCM" / 856 srtp-crypto-suite-ext 858 14.2. DTLS 860 DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; it 861 also corresponds to the use of an AEAD algorithm in SRTP. In order 862 to allow the use of the algorithms defined in this document in 863 DTLS-SRTP, we request IANA register the following SRTP Protection 864 Profiles: 866 AEAD_AES_128_CCM 867 cipher: AES_128_CCM 868 cipher_key_length: 128 bits 869 cipher_salt_length: 96 bits 870 maximum lifetime: at most 2^31 SRTCP packets and 871 at most 2^48 SRTP packets 873 AEAD_AES_256_CCM 874 cipher: AES_256_CCM 875 cipher_key_length: 256 bits 876 cipher_salt_length: 96 bits 877 maximum lifetime: at most 2^31 SRTCP packets and 878 at most 2^48 SRTP packets 880 AEAD_AES_128_CCM_8 881 cipher: AES_128_CCM 882 cipher_key_length: 128 bits 883 cipher_salt_length: 96 bits 884 maximum lifetime: at most 2^31 SRTCP packets and 885 at most 2^48 SRTP packets 887 AEAD_AES_256_CCM_8 888 cipher: AES_256_CCM 889 cipher_key_length: 256 bits 890 cipher_salt_length: 96 bits 891 maximum lifetime: at most 2^31 SRTCP packets and 892 at most 2^48 SRTP packets 894 AEAD_AES_128_CCM_12 895 cipher: AES_128_CCM 896 cipher_key_length: 128 bits 897 cipher_salt_length: 96 bits 898 maximum lifetime: at most 2^31 SRTCP packets and 899 at most 2^48 SRTP packets 901 AEAD_AES_256_CCM_12 902 cipher: AES_256_CCM 903 cipher_key_length: 256 bits 904 cipher_salt_length: 96 bits 905 maximum lifetime: at most 2^31 SRTCP packets and 906 at most 2^48 SRTP packets 908 AEAD_AES_128_GCM 909 cipher: AES_128_GCM 910 cipher_key_length: 128 bits 911 cipher_salt_length: 96 bits 912 maximum lifetime: at most 2^31 SRTCP packets and 913 at most 2^48 SRTP packets 915 AEAD_AES_256_GCM 916 cipher: AES_256_GCM 917 cipher_key_length: 256 bits 918 cipher_salt_length: 96 bits 919 maximum lifetime: at most 2^31 SRTCP packets and 920 at most 2^48 SRTP packets 922 AEAD_AES_128_GCM_8 923 cipher: AES_128_GCM 924 cipher_key_length: 128 bits 925 cipher_salt_length: 96 bits 926 maximum lifetime: at most 2^31 SRTCP packets and 927 at most 2^48 SRTP packets 929 AEAD_AES_256_GCM_8 930 cipher: AES_256_GCM 931 cipher_key_length: 256 bits 932 cipher_salt_length: 96 bits 933 maximum lifetime: at most 2^31 SRTCP packets and 934 at most 2^48 SRTP packets 936 AEAD_AES_128_GCM_12 937 cipher: AES_128_GCM 938 cipher_key_length: 128 bits 939 cipher_salt_length: 96 bits 940 maximum lifetime: at most 2^31 SRTCP packets and 941 at most 2^48 SRTP packets 943 AEAD_AES_256_GCM_12 944 cipher: AES_256_GCM 945 cipher_key_length: 256 bits 946 cipher_salt_length: 96 bits 947 maximum lifetime: at most 2^31 SRTCP packets and 948 at most 2^48 SRTP packets 950 Note that these SRTP Protection Profiles do not specify an 951 auth_function, auth_key_length, or auth_tag_length because all of 952 these profiles use AEAD algorithms, and thus do not use a separate 953 auth_function, auth_key, or auth_tag. 955 14.3. MIKEY 957 In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], 958 IANA maintains several Payload Name Spaces under Multimedia Internet 959 KEYing (MIKEY). This document requires additions to two of the lists 960 maintained under MIKEY Security Protocol Parameters. 962 On the SRTP policy Type/Value list (derived from Table 6.10.1.a of 963 [RFC3830]) we request the following addition: 965 Type | Meaning | Possible values 966 ---------------------------------------------------------------- 967 TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) 969 On the Encryption Algorithm List (derived from Table 6.10.1.b of 970 [RFC3830]) we request the following additions: 972 SRTP encr alg. | Value | Default Session Encr. Key Length 973 ----------------------------------------------------------- 974 AES-CCM | TBD | 16 octets 975 AES-GCM | TBD | 16 octets 977 The SRTP encryption algorithm, session encryption key length, and 978 AEAD authentication tag values received from MIKEY fully determine 979 the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is 980 described in section 15. 982 14.4. AEAD registry 984 We request that IANA make the following additions to the AEAD 985 registry: 987 AEAD_AES_128_CCM_12 = TBD 988 AEAD_AES_256_CCM_12 = TBD 990 15. Parameters for use with MIKEY 992 MIKEY specifies the algorithm family separately from the key length 993 (which is specified by the Session Encryption key length ) and the 994 authentication tag length (specified by AEAD Auth. tag length). 996 +------------+-------------+-------------+ 997 | Encryption | Encryption | AEAD Auth. | 998 | Algorithm | Key Length | Tag Length | 999 +============+=============+=============+ 1000 AEAD_AES_128_GCM | AES-GCM | 16 octets | 16 octets | 1001 +------------+-------------+-------------+ 1002 AEAD_AES_128_CCM | AES-CCM | 16 octets | 16 octets | 1003 +------------+-------------+-------------+ 1004 AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets | 1005 +------------+-------------+-------------+ 1006 AEAD_AES_128_CCM_12 | AES-CCM | 16 octets | 12 octets | 1007 +------------+-------------+-------------+ 1009 AEAD_AES_128_GCM_8 | AES-GCM | 16 octets | 8 octets | 1010 +------------+-------------+-------------+ 1011 AEAD_AES_128_CCM_8 | AES-CCM | 16 octets | 8 octets | 1012 +------------+-------------+-------------+ 1013 AEAD_AES_256_GCM | AES-GCM | 32 octets | 16 octets | 1014 +------------+-------------+-------------+ 1015 AEAD_AES_256_CCM | AES-CCM | 32 octets | 16 octets | 1016 +------------+-------------+-------------+ 1017 AEAD_AES_256_GCM_12 | AES-GCM | 32 octets | 12 octets | 1018 +------------+-------------+-------------+ 1019 AEAD_AES_256_CCM_12 | AES-CCM | 32 octets | 12 octets | 1020 +------------+-------------+-------------+ 1021 AEAD_AES_256_GCM_8 | AES-GCM | 32 octets | 8 octets | 1022 +------------+-------------+-------------+ 1023 AEAD_AES_256_CCM_8 | AES-CCM | 32 octets | 8 octets | 1024 +============+=============+=============+ 1026 Table 4: Mapping MIKEY parameters to AEAD algorithm 1028 Section 12 in this document restricts the choice of Key Derivation 1029 Function for AEAD algorithms. To enforce this restriction in MIKEY, 1030 we require that the SRTP PRF has value AES-CM whenever an AEAD 1031 algorithm is used. Note that, according to Section 6.10.1 in 1032 [RFC3830], the key length of the Key Derivation Function (i.e. the 1033 SRTP master key length) is always equal to the session encryption key 1034 length. This means, for example, that AEAD_AES_256_GCM will use 1035 AES_256_CM_PRF as the Key Derivation Function. 1037 16. Acknowledgements 1039 The authors would like to thank Michael Peck, Michael Torla, Qin Wu, 1040 Magnus Westerland, Oscar Ohllson and many other reviewers who 1041 provided valuable comments on earlier drafts of this document. 1043 17. References 1045 17.1. Normative References 1047 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM 1048 Mode for Authentication and Confidentiality", U.S. 1049 National Institute of Standards and Technology http:// 1050 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf. 1052 [GCM] Dworkin, M., "NIST Special Publication 800-38D: 1053 Recommendation for Block Cipher Modes of Operation: 1054 Galois/Counter Mode (GCM) and GMAC.", U.S. National 1055 Institute of Standards and Technology http:// 1056 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf. 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, March 1997. 1061 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and 1062 K. Norrman, "The Secure Real-time Transport Protocol 1063 (SRTP)", RFC 3711, March 2004. 1065 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,and 1066 Norrman, K, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1067 August 2004. 1069 [RFC4568] Andreasen, F., Baugher, M., and D.Wing, "Session 1070 Description Protocol (SDP): Security Descriptions for 1071 Media Streams", RFC 4568, July 2006. 1073 [RFC5116] McGrew, D., "An Interface and Algorithms for 1074 Authenticated Encryption with Associated Data", RFC 5116, 1075 January 2008. 1077 [RFC5282] McGrew, D. and D. Black, "Using Authenticated Encryption 1078 Algorithms with the Encrypted Payload of the Internet Key 1079 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. 1081 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1082 Security (DTLS) Extension to Establish Keys for the Secure 1083 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1085 [RFC6188] McGrew,D.,"The Use of AES-192 and AES-256 in Secure RTP" 1086 RFC 6188, March 2011 1088 [RFC6655] McGrew,D. and D. Bailey,"AES-CCM Cipher Suites for Transport 1089 Layer Security (TLS)", July 2012 1091 17.2. Informative References 1093 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption: 1094 Relations among notions and analysis of the generic 1095 composition paradigm", Proceedings of ASIACRYPT 2000, 1096 Springer-Verlag, LNCS 1976, pp. 531-545 http:// 1097 www-cse.ucsd.edu/users/mihir/papers/oem.html. 1099 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication 1100 and Key Establishment", Springer, 2003 . 1102 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 1103 CryptoToolkit/modes/800-38_Series_Publications/ 1104 SP800-38B.pdf. 1106 [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and 1107 provably repairing the SSH authenticated encryption 1108 scheme: A case study of the Encode-then-Encrypt-and-MAC 1109 paradigm", ACM Transactions on Information and System Secu 1110 rity, http://www-cse.ucsd.edu/users/tkohno/papers/ 1111 TISSEC04/. 1113 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder 1114 than Real: Security Challenges in Virtual Machine Based 1115 Computing Environments", Proceedings of the 10th Workshop 1116 on Hot Topics in Operating Systems http:// 1117 www.stanford.edu/~talg/papers/HOTOS05/ 1118 virtual-harder-hotos05.pdf. 1120 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC", 1121 Proceedings of the 9th Annual Workshop on Selected Areas 1122 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/ 1123 proposedmodes/ccm/ccm-ad1.pdf, 2002. 1125 [MODES] Dworkin, M., "NIST Special Publication 800-38: 1126 Recommendation for Block Cipher Modes of Operation", U.S. 1127 National Institute of Standards and Technology http:// 1128 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. 1130 [MV04] McGrew, D. and J. Viega, "The Security and Performance of 1131 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT 1132 '04, http://eprint.iacr.org/2004/193, December 2004. 1134 [R02] Rogaway, P., "Authenticated encryption with Associated- 1135 Data", ACM Conference on Computer and Communication 1136 Security (CCS'02), pp. 98-107, ACM Press, 1137 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html. 1139 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1140 Hashing for Message Authentication", RFC 2104, 1141 February 1997. 1143 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1144 Requirements for Security", BCP 106, RFC 4086, June 2005. 1146 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1147 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1148 RFC 4106, June 2005. 1150 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1151 Key Management", BCP 107, RFC 4107, June 2005. 1153 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1154 RFC 4303, December 2005. 1156 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1157 Mode with IPsec Encapsulating Security Payload (ESP)", 1158 RFC 4309, December 2005. 1160 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1161 Transform Carrying Roll-Over Counter for the Secure Real- 1162 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1164 Author's Address 1166 David A. McGrew 1167 Cisco Systems, Inc. 1168 510 McCarthy Blvd. 1169 Milpitas, CA 95035 1170 US 1171 Phone: (408) 525 8651 1172 Email: mcgrew@cisco.com 1173 URI: http://www.mindspring.com/~dmcgrew/dam.htm 1175 Kevin M. Igoe 1176 NSA/CSS Commercial Solutions Center 1177 National Security Agency 1178 EMail: kmigoe@nsa.gov 1180 Acknowledgement 1182 Funding for the RFC Editor function is provided by the IETF 1183 Administrative Support Activity (IASA).