idnits 2.17.1 draft-ietf-avt-srtp-big-aes-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 471 has weird spacing: '...cfdfeff cea5...' == Line 573 has weird spacing: '...cfdfeff d108...' -- 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 (January 12, 2011) is 4853 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 392, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 Intended status: Standards Track January 12, 2011 5 Expires: July 16, 2011 7 The use of AES-192 and AES-256 in Secure RTP 8 draft-ietf-avt-srtp-big-aes-06.txt 10 Abstract 12 This memo describes the use of the Advanced Encryption Standard (AES) 13 with 192 and 256 bit keys within the Secure RTP protocol. It details 14 Counter Mode encryption for SRTP and SRTCP and a new SRTP Key 15 Derivation Function (KDF) for AES-192 and AES-256. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 16, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 53 2. AES-192 and AES-256 Encryption . . . . . . . . . . . . . . . . 4 54 3. The AES_192_CM_PRF and AES_256_CM_PRF Key Derivation 55 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Usage Requirements . . . . . . . . . . . . . . . . . . . . 6 57 4. Crypto Suites . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 60 7. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 7.1. AES-256-CM Test Cases . . . . . . . . . . . . . . . . . . 14 62 7.2. AES_256_CM_PRF Test Cases . . . . . . . . . . . . . . . . 14 63 7.3. AES-192-CM Test Cases . . . . . . . . . . . . . . . . . . 16 64 7.4. AES_192_CM_PRF Test Cases . . . . . . . . . . . . . . . . 16 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 71 1. Introduction 73 This memo describes the use of the Advanced Encryption Standard (AES) 74 [FIPS197] with 192 and 256 bit keys within the Secure RTP protocol 75 [RFC3711]. Below those block ciphers are referred to as AES-192 and 76 AES-256, respectively, and the use of AES with a 128 bit key is 77 referred to as AES-128. This document describes Counter Mode 78 encryption for SRTP and SRTCP and appropriate SRTP Key Derivation 79 Functions for AES-192 and AES-256. It also defines new cryptosuites 80 that use these new functions. 82 While AES-128 is widely regarded as more than adequately secure, some 83 users may be motivated to adopt AES-192 or AES-256 due to a perceived 84 need to purse a highly conservative security strategy. For instance, 85 the Suite B profile requires AES-256 for the protection of TOP SECRET 86 information [suiteB]. (Note that while the AES-192 and AES-256 87 encryption methods defined in this document use Suite B algorithms, 88 the cryptosuites in this document use the HMAC-SHA-1 algorithm, which 89 is not included in Suite B.) See Section 6 for more discussion of 90 security issues. 92 The crypto functions described in this document are an addition to, 93 and not a replacement for, the crypto functions defined in [RFC3711]. 95 1.1. Conventions Used In This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. AES-192 and AES-256 Encryption 103 Section 4.1.1 of [RFC3711] defines AES counter mode encryption, which 104 it refers to as AES_CM. This definition applies to all of the AES 105 key sizes. In this note, AES-192 counter mode and AES-256 counter 106 mode and are denoted as AES_192_CM and AES_256_CM respectively. In 107 both of these ciphers, the plaintext inputs to the block cipher are 108 formed as in AES_CM, and the block cipher outputs are processed as in 109 AES_CM. The only difference in the processing is that AES_192_CM 110 uses AES-192, and AES_256_CM uses AES-256. Both AES_192_CM and 111 AES_256_CM use a 112-bit salt as an input, as does AES_CM. 113 For the convenience of the reader, the structure of the counter 114 blocks in SRTP counter mode encryption is illustrated in Figure 1, 115 using the terminology from Section 4.1.1 of [RFC3711]. In this 116 diagram, the symbol (+) denotes the bitwise exclusive-or operation, 117 and the AES encrypt operation uses AES-128, AES-192, or AES-256 for 118 AES_CM, AES_192_CM, and AES_256_CM, respectively. The field labeled 119 b_c contains a block counter, the value of which increments once for 120 each invocation of the "AES Encrypt" function. The SSRC field is 121 part of the RTP header [RFC3550]. 123 one octet 124 <--> 125 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 126 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 127 |00|00|00|00| SSRC | packet index | b_c |---+ 128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 129 | 130 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ v 131 | salt (k_s) |00|00|->(+) 132 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 133 | 134 v 135 +-------------+ 136 encryption key (k_e) -> | AES encrypt | 137 +-------------+ 138 | 139 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 140 | keystream block |<--+ 141 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 143 Figure 1: AES Counter Mode. 145 3. The AES_192_CM_PRF and AES_256_CM_PRF Key Derivation Functions 147 Section 4.3.3 of [RFC3711] defines an AES counter mode key derivation 148 function, which it refers to as AES_CM PRF (and sometimes as AES-CM 149 PRF). (That specification uses the term PRF, or pseudo-random 150 function, interchangeably with the phrase "key derivation function". 151 ) This key derivation function can be used with any AES key size. In 152 this note, the AES-192 counter mode PRF and AES-256 counter mode PRF 153 are denoted as AES_192_CM_PRF and AES_256_CM_PRF respectively. In 154 both of these PRFs, the plaintext inputs to the block cipher are 155 formed as in the AES_CM PRF, and the block cipher outputs are 156 processed as in the AES_CM PRF. The only difference in the 157 processing is that AES_192_CM_PRF uses AES-192, and AES_256_CM_PRF 158 uses AES-256. Both AES_192_CM_PRF and AES_256_CM_PRF use a 112-bit 159 salt as an input, as does the AES_CM PRF. 161 For the convenience of the reader, the structure of the counter 162 blocks in SRTP counter mode key derivation is illustrated in 163 Figure 2, using the terminology from Section 4.3.3 of [RFC3711]. In 164 this diagram, the symbol (+) denotes the bitwise exclusive-or 165 operation, and the "AES Encrypt" operation uses AES-128, AES-192, or 166 AES-256 for the AES_CM PRF, AES_192_CM_PRF, and AES_256_CM_PRF, 167 respectively. The field "LB" contains the 8-bit constant "label" 168 which is provided as an input to the key derivation function (and 169 which is distinct for each type of key generated by that function). 170 The field labeled b_c contains a block counter, the value of which 171 increments once for each invocation of the "AES Encrypt" function. 172 The DIV operation is defined in Section 4.3.1 of [RFC3711] as 173 follows. Let "a DIV t" denote integer division of a by t, rounded 174 down, and with the convention that "a DIV 0 = 0" for all a. We also 175 make the convention of treating "a DIV t" as a bit string of the same 176 length as a, and thus "a DIV t" will in general have leading zeros. 178 one octet 179 <--> 180 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 181 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 182 |00|00|00|00|00|00|00|LB| index DIV kdr | b_c |---+ 183 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 184 | 185 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ v 186 | master salt |00|00|->(+) 187 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 188 | 189 v 190 +-------------+ 191 master key -> | AES encrypt | 192 +-------------+ 193 | 194 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 195 | output block |<--+ 196 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 198 Figure 2: The AES counter mode Key Derivation Function 200 3.1. Usage Requirements 202 When AES_192_CM is used for encryption, AES_192_CM_PRF SHOULD be used 203 as the key derivation function, and AES_128_CM_PRF MUST NOT be used 204 as the key derivation function. 206 When AES_256_CM is used for encryption, AES_256_CM_PRF SHOULD be used 207 as the key derivation function. Both AES_128_CM_PRF and 208 AES_192_CM_PRF MUST NOT be used as the key derivation function. 210 AES_256_CM_PRF MAY be used as the key derivation function when AES_CM 211 is used for encryption, and when AES_192_CM is used for encryption. 212 AES_192_CM_PRF MAY be used as the key derivation function when AES_CM 213 is used for encryption. 215 Rationale: it is essential that the cryptographic strength of the 216 key derivation meets or exceeds that of the encryption method. It 217 is natural to use the same function for both encryption and key 218 derivation. However, it is not required to do so because it is 219 desirable to allow these ciphers to be used with alternative key 220 derivation functions that may be defined in the future. 222 4. Crypto Suites 224 This section defines SRTP crypto suites that use the ciphers and key 225 derivation functions defined in this document. The parameters in 226 these crypto suites are described in Section 8.2 of [RFC3711]. These 227 suites are registered with IANA for use with the SDP Security 228 Descriptions attributes (Section 10.3.2.1 of [RFC4568]). Other SRTP 229 key management methods that use the crypto functions defined in this 230 document are encouraged to also use these crypto suite definitions. 232 Rationale: the crypto suites use the same authentication function 233 that is mandatory-to-implement in SRTP, HMAC-SHA1 with a 160 bit 234 key. HMAC-SHA1 would accept larger key sizes, but when it is used 235 with keys larger than 160 bits, it does not provide resistance to 236 cryptanalysis greater than that security level, because it has 237 only 160 bits of internal state. By retaining 160-bit 238 authentication keys, the crypto suites in this note have more 239 compatibility with existing crypto suites and implementations of 240 them. 242 +------------------------------+------------------------------------+ 243 | Parameter | Value | 244 +------------------------------+------------------------------------+ 245 | Master key length | 192 bits | 246 | | | 247 | Master salt length | 112 bits | 248 | | | 249 | Key Derivation Function | AES_192_CM_PRF (Section 3) | 250 | | | 251 | Default key lifetime | 2^31 packets | 252 | | | 253 | Cipher (for SRTP and SRTCP) | AES_192_CM (Section 2) | 254 | | | 255 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 256 | | [RFC3711]) | 257 | | | 258 | SRTP authentication key | 160 bits | 259 | length | | 260 | | | 261 | SRTP authentication tag | 80 bits | 262 | length | | 263 | | | 264 | SRTCP authentication | HMAC-SHA1 (Section 4.2.1 of | 265 | function | [RFC3711]) | 266 | | | 267 | SRTCP authentication key | 160 bits | 268 | length | | 269 | | | 270 | SRTCP authentication tag | 80 bits | 271 | length | | 272 +------------------------------+------------------------------------+ 274 Table 1: The AES_192_CM_HMAC_SHA1_80 cryptosuite. 276 +------------------------------+------------------------------------+ 277 | Parameter | Value | 278 +------------------------------+------------------------------------+ 279 | Master key length | 192 bits | 280 | | | 281 | Master salt length | 112 bits | 282 | | | 283 | Key Derivation Function | AES_192_CM_PRF (Section 3) | 284 | | | 285 | Default key lifetime | 2^31 packets | 286 | | | 287 | Cipher (for SRTP and SRTCP) | AES_192_CM (Section 2) | 288 | | | 289 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 290 | | [RFC3711]) | 291 | | | 292 | SRTP authentication key | 160 bits | 293 | length | | 294 | | | 295 | SRTP authentication tag | 32 bits | 296 | length | | 297 | | | 298 | SRTCP authentication | HMAC-SHA1 (Section 4.2.1 of | 299 | function | [RFC3711]) | 300 | | | 301 | SRTCP authentication key | 160 bits | 302 | length | | 303 | | | 304 | SRTCP authentication tag | 80 bits | 305 | length | | 306 +------------------------------+------------------------------------+ 308 Table 2: The AES_192_CM_HMAC_SHA1_32 cryptosuite. 310 +------------------------------+------------------------------------+ 311 | Parameter | Value | 312 +------------------------------+------------------------------------+ 313 | Master key length | 256 bits | 314 | | | 315 | Master salt length | 112 bits | 316 | | | 317 | Key Derivation Function | AES_256_CM_PRF (Section 3) | 318 | | | 319 | Default key lifetime | 2^31 packets | 320 | | | 321 | Cipher (for SRTP and SRTCP) | AES_256_CM (Section 2) | 322 | | | 323 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 324 | | [RFC3711]) | 325 | | | 326 | SRTP authentication key | 160 bits | 327 | length | | 328 | | | 329 | SRTP authentication tag | 80 bits | 330 | length | | 331 | | | 332 | SRTCP authentication | HMAC-SHA1 (Section 4.2.1 of | 333 | function | [RFC3711]) | 334 | | | 335 | SRTCP authentication key | 160 bits | 336 | length | | 337 | | | 338 | SRTCP authentication tag | 80 bits | 339 | length | | 340 +------------------------------+------------------------------------+ 342 Table 3: The AES_256_CM_HMAC_SHA1_80 cryptosuite. 344 +------------------------------+------------------------------------+ 345 | Parameter | Value | 346 +------------------------------+------------------------------------+ 347 | Master key length | 256 bits | 348 | | | 349 | Master salt length | 112 bits | 350 | | | 351 | Key Derivation Function | AES_256_CM_PRF (Section 3) | 352 | | | 353 | Default key lifetime | 2^31 packets | 354 | | | 355 | Cipher (for SRTP and SRTCP) | AES_256_CM (Section 2) | 356 | | | 357 | SRTP authentication function | HMAC-SHA1 (Section 4.2.1 of | 358 | | [RFC3711]) | 359 | | | 360 | SRTP authentication key | 160 bits | 361 | length | | 362 | | | 363 | SRTP authentication tag | 32 bits | 364 | length | | 365 | | | 366 | SRTCP authentication | HMAC-SHA1 (Section 4.2.1 of | 367 | function | [RFC3711]) | 368 | | | 369 | SRTCP authentication key | 160 bits | 370 | length | | 371 | | | 372 | SRTCP authentication tag | 80 bits | 373 | length | | 374 +------------------------------+------------------------------------+ 376 Table 4: The AES_256_CM_HMAC_SHA1_32 cryptosuite. 378 5. IANA Considerations 380 IANA is expected to assign the following parameters in the Session 381 Description Protocol (SDP) Security Descriptions registry. 383 +-------------------------+-----------+ 384 | Crypto Suite Name | Reference | 385 +-------------------------+-----------+ 386 | AES_192_CM_HMAC_SHA1_80 | [RFCxxxx] | 387 | | | 388 | AES_192_CM_HMAC_SHA1_32 | [RFCxxxx] | 389 | | | 390 | AES_256_CM_HMAC_SHA1_80 | [RFCxxxx] | 391 | | | 392 | AES_256_CM_HMAC_SHA1_32 | [RFCxxxx] | 393 +-------------------------+-----------+ 395 Note to RFC Editor: Replace RFCxxx with the number of this RFC. 397 6. Security Considerations 399 AES-128 provides a level of security that is widely regarded as being 400 more than sufficient for providing confidentiality. It is believed 401 that the economic cost of breaking AES-128 is significantly higher 402 than the cost of more direct approaches to violating system security, 403 e.g. theft, bribery, wiretapping, and other forms of malfeasance. 405 Future advances in the state of the art of cryptanalysis could 406 eliminate this confidence in AES-128, and motivate the use of AES-192 407 or AES-256. AES-192 is regarded as being secure even against some 408 adversaries for which breaking AES-128 may be feasible. Similarly, 409 AES-256 is regarded as being secure even against some adversaries for 410 which it may be feasible to break AES-192. The availability of the 411 larger key size versions of AES provides a fallback plan in case of 412 unanticipated cryptanalytic results. 414 It is conjectured that AES-256 provides adequate security even 415 against adversaries that possess the ability to construct a quantum 416 computer that works on 256 or more quantum bits. No such computer is 417 known to exist; its feasibility is an area of active speculation and 418 research. 420 Despite the apparent sufficiency of AES-128, some users are 421 interested in the larger AES key sizes. For some applications, the 422 40% increase in computational cost for AES-256 over AES-128 is a 423 worthwhile bargain when traded for the security advantages outlined 424 above. These applications include those with a perceived need for 425 very high security, e.g. due to a desire for very long-term 426 confidentiality. 428 AES-256 (as it is used in this note) provides the highest level of 429 security, and it SHOULD be used whenever the highest possible 430 security is desired. AES-192 provides a middle ground between the 431 128-bit and 256-bit versions of AES, and it MAY be used when security 432 higher than that of AES-128 is desired. In this note, AES-192 and 433 AES-256 are used with keys that are generated via a strong 434 pseudorandom source, and thus the related-key attacks that have been 435 described in the theoretical literature are not applicable. 437 As with any cipher, the conjectured security level of AES may change 438 over time. The considerations in this section reflect the best 439 knowledge available at the time of publication of this document. 441 It is desirable that AES_192_CM and AES_192_CM_PRF be used with an 442 authentication function that uses a 192 bit key, and that AES_256_CM 443 and AES_256_CM_PRF be used with an authentication function that uses 444 a 256 bit key. However, this desire is not regarded as security- 445 critical. Cryptographic authentication is resilient against future 446 advances in cryptanalysis, since the opportunity for a forgery attack 447 against a session closes when that session closes. For this reason, 448 this note defines new ciphers, but not new authentication functions. 450 7. Test Cases 452 The test cases in this section are based on Appendix B of [RFC3711]. 454 7.1. AES-256-CM Test Cases 456 Keystream segment length: 1044512 octets (65282 AES blocks) 457 Session Key: 57f82fe3613fd170a85ec93c40b1f092 458 2ec4cb0dc025b58272147cc438944a98 459 Rollover Counter: 00000000 460 Sequence Number: 0000 461 SSRC: 00000000 462 Session Salt: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 (already shifted) 463 Offset: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 465 Counter Keystream 467 f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 92bdd28a93c3f52511c677d08b5515a4 468 f0f1f2f3f4f5f6f7f8f9fafbfcfd0001 9da71b2378a854f67050756ded165bac 469 f0f1f2f3f4f5f6f7f8f9fafbfcfd0002 63c4868b7096d88421b563b8c94c9a31 470 ... ... 471 f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff cea518c90fd91ced9cbb18c078a54711 472 f0f1f2f3f4f5f6f7f8f9fafbfcfdff00 3dbc4814f4da5f00a08772b63c6a046d 473 f0f1f2f3f4f5f6f7f8f9fafbfcfdff01 6eb246913062a16891433e97dd01a57f 475 7.2. AES_256_CM_PRF Test Cases 477 This section provides test data for the AES_256_CM_PRF key derivation 478 function, which uses AES-256 in Counter Mode. In the following, we 479 walk through the initial key derivation for the AES-256 Counter Mode 480 cipher, which requires a 32 octet session encryption key and a 14 481 octet session salt, and the HMAC-SHA1 authentication function, which 482 requires a 20-octet session authentication key. These values are 483 called the cipher key, the cipher salt, and the auth key in the 484 following. Since this is the initial key derivation and the key 485 derivation rate is equal to zero, the value of (index DIV 486 key_derivation_rate) is zero (actually, a six-octet string of zeros). 487 In the following, we shorten key_derivation_rate to kdr. 489 The inputs to the key derivation function are the 32 octet master key 490 and the 14 octet master salt: 492 master key: f0f04914b513f2763a1b1fa130f10e29 493 98f6f6e43e4309d1e622a0e332b9f1b6 494 master salt: 3b04803de51ee7c96423ab5b78d2 496 We first show how the cipher key is generated. The input block for 497 AES-256-CM is generated by exclusive-oring the master salt with the 498 concatenation of the encryption key label 0x00 with (index DIV kdr), 499 then padding on the right with two null octets (which implements the 500 multiply-by-2^16 operation, see Section 4.3.3 of RFC 3711). The 501 resulting value is then AES-256-CM- encrypted using the master key to 502 get the cipher key. 504 index DIV kdr: 000000000000 505 label: 00 506 master salt: 3b04803de51ee7c96423ab5b78d2 507 ----------------------------------------------- 508 xor: 3b04803de51ee7c96423ab5b78d2 (x, PRF input) 510 x*2^16: 3b04803de51ee7c96423ab5b78d20000 (AES-256-CM input) 511 x*2^16 + 1: 3b04803de51ee7c96423ab5b78d20001 (2nd AES input) 513 cipher key: 5ba1064e30ec51613cad926c5a28ef73 (1st AES output) 514 1ec7fb397f70a960653caf06554cd8c4 (2nd AES output) 516 Next, we show how the cipher salt is generated. The input block for 517 AES-256-CM is generated by exclusive-oring the master salt with the 518 concatenation of the encryption salt label. That value is padded and 519 encrypted as above. 521 index DIV kdr: 000000000000 522 label: 02 523 master salt: 3b04803de51ee7c96423ab5b78d2 525 ---------------------------------------------- 526 xor: 3b04803de51ee7cb6423ab5b78d2 (x, PRF input) 528 x*2^16: 3b04803de51ee7cb6423ab5b78d20000 (AES-256-CM input) 530 fa31791685ca444a9e07c6c64e93ae6b (AES-256 ouptut) 532 cipher salt: fa31791685ca444a9e07c6c64e93 534 We now show how the auth key is generated. The input block for AES- 535 256-CM is generated as above, but using the authentication key label. 537 index DIV kdr: 000000000000 538 label: 01 539 master salt: 3b04803de51ee7c96423ab5b78d2 540 ----------------------------------------------- 541 xor: 3b04803de51ee7c86423ab5b78d2 (x, PRF input) 543 x*2^16: 3b04803de51ee7c86423ab5b78d20000 (AES-256-CM in) 545 Below, the AES-256 output blocks that form the auth key are shown 546 on the left, while the corresponding AES-256 input blocks are shown 547 on the right. Note that the final AES-256 output is truncated to a 548 four-byte length. The final auth key is shown below. 550 auth key blocks AES-256 input blocks 551 fd9c32d39ed5fbb5a9dc96b30818454d 3b04803de51ee7c86423ab5b78d20000 552 1313dc05 3b04803de51ee7c86423ab5b78d20001 554 auth key: fd9c32d39ed5fbb5a9dc96b30818454d1313dc05 556 7.3. AES-192-CM Test Cases 558 Keystream segment length: 1044512 octets (65282 AES blocks) 559 Session Key: eab234764e517b2d3d160d587d8c8621 560 9740f65f99b6bcf7 561 Rollover Counter: 00000000 562 Sequence Number: 0000 563 SSRC: 00000000 564 Session Salt: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 (already shifted) 565 Offset: f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 567 Counter Keystream 569 f0f1f2f3f4f5f6f7f8f9fafbfcfd0000 35096cba4610028dc1b57503804ce37c 570 f0f1f2f3f4f5f6f7f8f9fafbfcfd0001 5de986291dcce161d5165ec4568f5c9a 571 f0f1f2f3f4f5f6f7f8f9fafbfcfd0002 474a40c77894bc17180202272a4c264d 572 ... ... 573 f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff d108d1a31a00bad6367ec23eb044b415 574 f0f1f2f3f4f5f6f7f8f9fafbfcfdff00 c8f57129fdeb970b59f917b257662d4c 575 f0f1f2f3f4f5f6f7f8f9fafbfcfdff01 a5dab625811034e8cebdfeb6dc158dd3 577 7.4. AES_192_CM_PRF Test Cases 579 This section provides test data for the AES_192_CM_PRF key derivation 580 function, which uses AES-192 in Counter Mode. In the following, we 581 walk through the initial key derivation for the AES-192 Counter Mode 582 cipher, which requires a 24 octet session encryption key and a 14 583 octet session salt, and the HMAC-SHA1 authentication function, which 584 requires a 20-octet session authentication key. These values are 585 called the cipher key, the cipher salt, and the auth key in the 586 following. Since this is the initial key derivation and the key 587 derivation rate is equal to zero, the value of (index DIV 588 key_derivation_rate) is zero (actually, a six-octet string of zeros). 589 In the following, we shorten key_derivation_rate to kdr. 591 The inputs to the key derivation function are the 24 octet master key 592 and the 14 octet master salt: 594 master key: 73edc66c4fa15776fb57f9505c171365 595 50ffda71f3e8e5f1 596 master salt: c8522f3acd4ce86d5add78edbb11 598 We first show how the cipher key is generated. The input block for 599 AES-192-CM is generated by exclusive-oring the master salt with the 600 concatenation of the encryption key label 0x00 with (index DIV kdr), 601 then padding on the right with two null octets (which implements the 602 multiply-by-2^16 operation, see Section 4.3.3 of RFC 3711). The 603 resulting value is then AES-192-CM encrypted using the master key to 604 get the cipher key. 606 index DIV kdr: 000000000000 607 label: 00 608 master salt: c8522f3acd4ce86d5add78edbb11 609 ----------------------------------------------- 610 xor: c8522f3acd4ce86d5add78edbb11 (x, PRF input) 612 x*2^16: c8522f3acd4ce86d5add78edbb110000 (AES-192-CM input) 613 x*2^16 + 1: c8522f3acd4ce86d5add78edbb110001 (2nd AES input) 615 cipher key: 31874736a8f1143870c26e4857d8a5b2 (1st AES output) 616 c4a354407faadabb (2nd AES output) 618 Next, we show how the cipher salt is generated. The input block for 619 AES-192-CM is generated by exclusive-oring the master salt with the 620 concatenation of the encryption salt label. That value is padded and 621 encrypted as above. 623 index DIV kdr: 000000000000 624 label: 02 625 master salt: c8522f3acd4ce86d5add78edbb11 627 ---------------------------------------------- 628 xor: c8522f3acd4ce86f5add78edbb11 (x, PRF input) 630 x*2^16: c8522f3acd4ce86f5add78edbb110000 (AES-192-CM input) 632 2372b82d639b6d8503a47adc0a6c2590 (AES-192 ouptut) 634 cipher salt: 2372b82d639b6d8503a47adc0a6c 636 We now show how the auth key is generated. The input block for AES- 637 192-CM is generated as above, but using the authentication key label. 639 index DIV kdr: 000000000000 640 label: 01 641 master salt: c8522f3acd4ce86d5add78edbb11 642 ----------------------------------------------- 643 xor: c8522f3acd4ce86c5add78edbb11 (x, PRF input) 645 x*2^16: c8522f3acd4ce86c5add78edbb110000 (AES-192-CM in) 647 Below, the AES-192 output blocks that form the auth key are shown 648 on the left, while the corresponding AES-192 input blocks are shown 649 on the right. Note that the final AES-192 output is truncated to a 650 four-byte length. The final auth key is shown below. 652 auth key blocks AES-192 input blocks 653 355b10973cd95b9eacf4061c7e1a7151 c8522f3acd4ce86c5add78edbb110000 654 e7cfbfcb c8522f3acd4ce86c5add78edbb110001 656 auth key: 355b10973cd95b9eacf4061c7e1a7151e7cfbfcb 658 8. Acknowledgements 660 Thanks are due to John Mattsson for verifying the test cases in the 661 document and providing comments, to Bob Bell for feedback and 662 encouragement, and to Richard Barnes and Hilarie Orman for 663 constructive review. 665 9. References 667 9.1. Normative References 669 [FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal 670 Information Processing Standard. 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, March 1997. 675 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 676 Jacobson, "RTP: A Transport Protocol for Real-Time 677 Applications", STD 64, RFC 3550, July 2003. 679 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 680 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 681 RFC 3711, March 2004. 683 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 684 Description Protocol (SDP) Security Descriptions for Media 685 Streams", RFC 4568, July 2006. 687 9.2. Informative References 689 [suiteB] "Suite B Cryptography", http://www.nsa.gov/ia/programs/ 690 suiteb_cryptography/index.shtml. 692 Author's Address 694 David A. McGrew 695 Cisco Systems, Inc. 696 510 McCarthy Blvd. 697 Milpitas, CA 95035 698 US 700 Phone: (408) 525 8651 701 Email: mcgrew@cisco.com 702 URI: http://www.mindspring.com/~dmcgrew/dam.htm