idnits 2.17.1 draft-mcgrew-srtp-big-aes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 479. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2006) is 6575 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). 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 Expires: October 28, 2006 April 26, 2006 6 The use of AES-192 and AES-256 in Secure RTP 7 draft-mcgrew-srtp-big-aes-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 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 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 28, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This memo describes the use of the Advanced Encryption Standard (AES) 41 with 192 and 256 bit keys within the Secure RTP protocol. It defines 42 Counter Mode encryption for SRTP and SRTCP and a new SRTP Key 43 Derivation Function (KDF) for AES-192 and AES-256. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Conventions Used In This Document . . . . . . . . . . . . 3 49 2. AES-192 and AES-256 Encryption . . . . . . . . . . . . . . . 4 50 3. The AES_CM_192_PRF and AES_CM_256_PRF Key Derivation 51 Functions . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1 Usage Requirements . . . . . . . . . . . . . . . . . . . . 6 53 4. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Crypto Suties . . . . . . . . . . . . . . . . . . . . . . . 8 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 56 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 57 8. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 14 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 61 10.2 Informative References . . . . . . . . . . . . . . . . . 16 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 63 Intellectual Property and Copyright Statements . . . . . . . 17 65 1. Introduction 67 This memo describes the use of the Advanced Encryption Standard (AES) 68 [FIPS197] with 192 and 256 bit keys within the Secure RTP protocol 69 [RFC3711]. Below those block ciphers are referred to as AES-192 and 70 AES-256, respectively, and the use of AES with a 128 bit key is 71 referred to as AES-128. This document defines Counter Mode 72 encryption for SRTP and SRTCP and a new SRTP Key Derivation Function 73 for AES-192 and AES-256. It also defines new cryptosuites that use 74 these new functions. 76 While AES-128 is widely regarded as more than adequately secure, some 77 users may be motivated to adopt AES-192 or AES-256. One motivation 78 is conformance to the Suite B profile (which requires AES-256 for the 79 protection of TOP SECRET information) [suiteB]. Others may be 80 motivated by a perceived need to purse a highly conservative security 81 strategy; see Section 7 for more discussion of security issues. 83 The crypto functions defined in this document are an addition to, and 84 not a replacement for, the crypto functions defined in [RFC3711]. 86 1.1 Conventions Used In This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. AES-192 and AES-256 Encryption 94 Section 4.1.1 of [RFC3711] defines AES-128 counter mode encryption, 95 which it refers to as AES_CM. AES-192 counter mode and AES-256 96 counter mode are defined in a similar manner, and are denoted as 97 AES_192_CM and AES_256_CM respectively. In both of these ciphers, 98 the plaintext inputs to the block cipher are formed as in AES_CM, and 99 the block cipher outputs are processed as in AES_CM. The only 100 difference in the processing is that AES_192_CM uses AES-192, and 101 AES_256_CM uses AES-256. Both AES_192_CM and AES_256_CM use a 112- 102 bit salt as an input, as does AES_CM. 104 For the convenience of the reader, the structure of the counter 105 blocks in SRTP counter mode encryption is illustrated in Figure 1, 106 using the terminology from Section 4.1.1 of [RFC3711] . In this 107 diagram, the symbol (+) denotes the bitwise exclusive-or operation, 108 and the AES encrypt operation uses AES-128, AES-192, or AES-256 for 109 AES_CM, AES_192_CM, and AES_256_CM, respectively. The field labeled 110 b_c contains a block counter, the value of which increments once for 111 each invocation of the "AES Encrypt" function. 113 one octet 114 <--> 115 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 116 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 117 |00|00|00|00| SSRC | packet index | b_c |---+ 118 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 119 | 120 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ v 121 | salt (k_s) |00|00|->(+) 122 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 123 | 124 v 125 +-------------+ 126 encryption key (k_e) -> | AES encrypt | 127 +-------------+ 128 | 129 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 130 | keystream block |<--+ 131 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 133 Figure 1: AES Counter Mode. 135 3. The AES_CM_192_PRF and AES_CM_256_PRF Key Derivation Functions 137 Section 4.3.3 of [RFC3711] defines AES-128 counter mode key 138 derivation function, which it refers to as "AES-CM PRF". (That 139 specification uses the term PRF, or pseudo-random function, 140 interchangeably with the term "key derivation function". ) The AES- 141 192 counter mode PRF and AES-256 counter mode PRF are defined in a 142 similar manner, and are denoted as AES_192_CM_PRF and AES_256_CM_PRF 143 respectively. In both of these PRFs, the plaintext inputs to the 144 block cipher are formed as in the AES-CM PRF, and the block cipher 145 outputs are processed as in the AES-CM PRF. The only difference in 146 the processing is that AES_192_CM_PRF uses AES-192, and 147 AES_256_CM_PRF uses AES-256. Both AES_192_CM_PRF and AES_256_CM_PRF 148 use a 112-bit salt as an input, as does the AES-CM PRF. 150 For the convenience of the reader, the structure of the counter 151 blocks in SRTP counter mode key derivation is illustrated in 152 Figure 2, using the terminology from Section 4.3.3 of [RFC3711]. In 153 this diagram, the symbol (+) denotes the bitwise exclusive-or 154 operation, and the "AES Encrypt" operation uses AES-128, AES-192, or 155 AES-256 for the "AES-CM PRF", AES_192_CM_PRF, and AES_256_CM_PRF, 156 respectively. The field "LB" contains the 8-bit constant "label" 157 which is provided as an input to the key derivation function (and 158 which is distint for each key generated by that function). The field 159 labeled b_c contains a block counter, the value of which increments 160 once for each invocation of the "AES Encrypt" function. 162 one octet 163 <--> 164 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 165 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 166 |00|00|00|00|00|00|00|LB| index DIV kdr | b_c |---+ 167 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 168 | 169 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ v 170 | master salt |00|00|->(+) 171 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 172 | 173 v 174 +-------------+ 175 master key -> | AES encrypt | 176 +-------------+ 177 | 178 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 179 | output block |<--+ 180 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 182 Figure 2: The AES counter mode Key Derivation Function 184 3.1 Usage Requirements 186 When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as 187 the key derivation function, and AES_128_CM MUST NOT be used as the 188 key derivation function. 190 When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as 191 the key derivation function. Both AES_128_CM and AES_192_CM MUST NOT 192 be used as the key derivation function. 194 Rationale: it is essential that the cryptographic strength of the 195 key derivation meets or exceeds that of the encryption method. It 196 is natural to use the same function for both encryption and key 197 derivation. However, it is not required to do so because it is 198 desirable to allow these ciphers to be used with alternative key 199 derivation functions that may be defined in the future. 201 4. Test Cases 203 In a future version of this document, this section will provide test 204 cases that can be used to validate implementations. 206 5. Crypto Suties 208 This section defines SRTP crypto suites that use the ciphers and key 209 derivation functions defined in this document. These suites are 210 registered with IANA for use with the SDP Security Descriptions 211 attributes (Section 10.3.2.1 of [I-D.ietf-mmusic-sdescriptions]). 212 Other SRTP key management methods that use the crypto functions 213 defined in this document are encouraged to also use these crypto 214 suite definitions. 216 +---------------------------------+---------------------------------+ 217 | Parameter | Value | 218 +---------------------------------+---------------------------------+ 219 | Master key length | 192 bits | 220 | | | 221 | Master salt length | 112 bits | 222 | | | 223 | Key Derivation Function | AES_192_CM_PRF (Section 3) | 224 | | | 225 | Default key lifetime | 2^31 packets | 226 | | | 227 | Cipher (for SRTP and SRTCP) | AES_192_CM (Section 2) | 228 | | | 229 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 230 | | [RFC3711]) | 231 | | | 232 | SRTP authentication key length | 160 bits | 233 | | | 234 | SRTP authentication tag length | 80 bits | 235 | | | 236 | SRTCP authentication function | HMAC-SHA1 (Section 4.2.1 of | 237 | | [RFC3711]) | 238 | | | 239 | SRTCP authentication key length | 160 bits | 240 | | | 241 | SRTCP authentication tag length | 80 bits | 242 +---------------------------------+---------------------------------+ 244 Table 1: The AES_CM_192_HMAC_SHA1_80 cryptosuite. 246 +---------------------------------+---------------------------------+ 247 | Parameter | Value | 248 +---------------------------------+---------------------------------+ 249 | Master key length | 192 bits | 250 | | | 251 | Master salt length | 112 bits | 252 | | | 253 | Key Derivation Function | AES_192_CM_PRF (Section 3) | 254 | | | 255 | Default key lifetime | 2^31 packets | 256 | | | 257 | Cipher (for SRTP and SRTCP) | AES_192_CM (Section 2) | 258 | | | 259 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 260 | | [RFC3711]) | 261 | | | 262 | SRTP authentication key length | 160 bits | 263 | | | 264 | SRTP authentication tag length | 32 bits | 265 | | | 266 | SRTCP authentication function | HMAC-SHA1 (Section 4.2.1 of | 267 | | [RFC3711]) | 268 | | | 269 | SRTCP authentication key length | 160 bits | 270 | | | 271 | SRTCP authentication tag length | 80 bits | 272 +---------------------------------+---------------------------------+ 274 Table 2: The AES_CM_192_HMAC_SHA1_32 cryptosuite. 276 +---------------------------------+---------------------------------+ 277 | Parameter | Value | 278 +---------------------------------+---------------------------------+ 279 | Master key length | 256 bits | 280 | | | 281 | Master salt length | 112 bits | 282 | | | 283 | Key Derivation Function | AES_256_CM_PRF (Section 3) | 284 | | | 285 | Default key lifetime | 2^31 packets | 286 | | | 287 | Cipher (for SRTP and SRTCP) | AES_256_CM (Section 2) | 288 | | | 289 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 290 | | [RFC3711]) | 291 | | | 292 | SRTP authentication key length | 160 bits | 293 | | | 294 | SRTP authentication tag length | 80 bits | 295 | | | 296 | SRTCP authentication function | HMAC-SHA1 (Section 4.2.1 of | 297 | | [RFC3711]) | 298 | | | 299 | SRTCP authentication key length | 160 bits | 300 | | | 301 | SRTCP authentication tag length | 80 bits | 302 +---------------------------------+---------------------------------+ 304 Table 3: The AES_CM_256_HMAC_SHA1_80 cryptosuite. 306 +---------------------------------+---------------------------------+ 307 | Parameter | Value | 308 +---------------------------------+---------------------------------+ 309 | Master key length | 256 bits | 310 | | | 311 | Master salt length | 112 bits | 312 | | | 313 | Key Derivation Function | AES_256_CM_PRF (Section 3) | 314 | | | 315 | Default key lifetime | 2^31 packets | 316 | | | 317 | Cipher (for SRTP and SRTCP) | AES_256_CM (Section 2) | 318 | | | 319 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 320 | | [RFC3711]) | 321 | | | 322 | SRTP authentication key length | 160 bits | 323 | | | 324 | SRTP authentication tag length | 32 bits | 325 | | | 326 | SRTCP authentication function | HMAC-SHA1 (Section 4.2.1 of | 327 | | [RFC3711]) | 328 | | | 329 | SRTCP authentication key length | 160 bits | 330 | | | 331 | SRTCP authentication tag length | 80 bits | 332 +---------------------------------+---------------------------------+ 334 Table 4: The AES_CM_256_HMAC_SHA1_32 cryptosuite. 336 6. IANA Considerations 338 IANA is expected to assign the following parameters for the SDP 339 Security Descriptions crypto suite attribute. 341 AES_CM_192_HMAC_SHA1_80 343 AES_CM_192_HMAC_SHA1_32 345 AES_CM_256_HMAC_SHA1_80 347 AES_CM_256_HMAC_SHA1_32 349 The cryptosuites are as defined in Section 5. 351 7. Security Considerations 353 AES-128 provides a level of security that is widely regarded as being 354 more than sufficient for providing confidentiality. It is believed 355 that the economic cost of breaking AES-128 is significantly higher 356 than the cost of more direct approaches to violating system security, 357 e.g. theft, bribery, wiretapping, and other forms of malfeasance. 359 Future advances in the state of the art of cryptanalysis could 360 eliminate this confidence in AES-128, and motivate the use of AES-192 361 or AES-256. AES-192 is regarded as being secure even against some 362 adversaries for which breaking AES-128 may be feasible. Similarly, 363 AES-256 is regarded as being secure even against some adversaries for 364 which it may be feasible to break AES-192. The availability of the 365 larger key size versions of AES provides a fallback plan in case of 366 unanticipated cryptanalytic results. 368 It is conjectured that AES-256 provides adequate security even 369 against adversaries that possess the ability to construct a quantum 370 computer that works on 256 or more quantum bits. No such computer is 371 known to exist; its feasibility is an area of active speculation and 372 research. 374 Despite the apparent sufficiency of AES-128, some users are 375 interested in the larger AES key sizes. For some applications, the 376 40% increase in computational cost for AES-256 over AES-128 is a 377 worthwhile bargain when traded for the security advantages outlined 378 above. These applications include those with a perceived need for 379 very high security, e.g. due to a desire for very long-term 380 confidentiality. 382 As with any cipher, the conjectured security level of AES may change 383 over time. The considerations in this section reflect the best 384 knowledge available at the time of publication of this document. 386 It is desirable that AES_192_CM and AES_192_CM_PRF be used with an 387 authentication function that uses a 192 bit key, and that AES_256_CM 388 and AES_256_CM_PRF be used with an authentication function that uses 389 a 256 bit key. However, this desire is not regarded as security- 390 critical. Cryptographic authentication is resilient against future 391 advances in cryptanalysis, since the opportunity for a forgery attack 392 against a session closes when that session closes. 394 8. Open Questions 396 It may be desirable to eliminate AES-192 altogether, leaving users 397 with the simpler choice of using AES-128 or AES-256. This option 398 preserves the possibility of Suite B conformance. Given that the 399 incremental computational cost of AES-256 over AES-192 is only 16%, 400 and the additional key storage overhead is only 33%, this option 401 imposes only a minimal burden on implementations. 403 It may be desirable to use AES in the Chained Message Authentication 404 Code (CMAC) mode of operation [CMAC] in conjunction with the ciphers 405 defined in this document, with the CMAC key size matching the counter 406 mode key size. This mode of operation can be used as a replacement 407 for HMAC-SHA1, and that use would provide an authentication function 408 with security that is directly comparable to AES-192 and AES-256. 409 This mode of operation has some additional benefits and may be worth 410 considering for secure RTP. 412 9. Acknowledgements 414 Thanks to Bob Bell for feedback and encouragement. 416 10. References 418 10.1 Normative References 420 [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal 421 Information Processing Standard. 423 [I-D.ietf-mmusic-sdescriptions] 424 Andreasen, F., "Session Description Protocol Security 425 Descriptions for Media Streams", 426 draft-ietf-mmusic-sdescriptions-12 (work in progress), 427 September 2005. 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 433 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 434 RFC 3711, March 2004. 436 10.2 Informative References 438 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/ 439 CryptoToolkit/modes/800-38_Series_Publications/ 440 SP800-38B.pdf. 442 [suiteB] "Fact Sheet for NSA Suite B Cryptography", 443 http://www.nsa.gov/ia/industry/crypto_suite_b.cfm. 445 Author's Address 447 David A. McGrew 448 Cisco Systems, Inc. 449 510 McCarthy Blvd. 450 Milpitas, CA 95035 451 US 453 Phone: (408) 525 8651 454 Email: mcgrew@cisco.com 455 URI: http://www.mindspring.com/~dmcgrew/dam.htm 457 Intellectual Property Statement 459 The IETF takes no position regarding the validity or scope of any 460 Intellectual Property Rights or other rights that might be claimed to 461 pertain to the implementation or use of the technology described in 462 this document or the extent to which any license under such rights 463 might or might not be available; nor does it represent that it has 464 made any independent effort to identify any such rights. Information 465 on the procedures with respect to rights in RFC documents can be 466 found in BCP 78 and BCP 79. 468 Copies of IPR disclosures made to the IETF Secretariat and any 469 assurances of licenses to be made available, or the result of an 470 attempt made to obtain a general license or permission for the use of 471 such proprietary rights by implementers or users of this 472 specification can be obtained from the IETF on-line IPR repository at 473 http://www.ietf.org/ipr. 475 The IETF invites any interested party to bring to its attention any 476 copyrights, patents or patent applications, or other proprietary 477 rights that may cover technology that may be required to implement 478 this standard. Please address the information to the IETF at 479 ietf-ipr@ietf.org. 481 Disclaimer of Validity 483 This document and the information contained herein are provided on an 484 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 485 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 486 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 487 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 488 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 491 Copyright Statement 493 Copyright (C) The Internet Society (2006). This document is subject 494 to the rights, licenses and restrictions contained in BCP 78, and 495 except as set forth therein, the authors retain all their rights. 497 Acknowledgment 499 Funding for the RFC Editor function is currently provided by the 500 Internet Society.