Internet Engineering Task Force (IETF) D. McGrew Request for Comments: 6188 Cisco Systems, Inc. Category: Standards Track March 2011 ISSN: 2070-1721
The Use of AES-192 and AES-256 in Secure RTP
Abstract
This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6188.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
McGrew Standards Track [Page 1]
RFC 6188 SRTP AES-192 and AES-256 March 2011
Table of Contents
1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................3 2. AES-192 and AES-256 Encryption ..................................3 3. The AES_192_CM_PRF and AES_256_CM_PRF Key Derivation Functions ..4 3.1. Usage Requirements .........................................5 4. Crypto Suites ...................................................6 5. IANA Considerations .............................................9 6. Security Considerations .........................................9 7. Test Cases .....................................................10 7.1. AES-256-CM Test Cases .....................................10 7.2. AES_256_CM_PRF Test Cases .................................11 7.3. AES-192-CM Test Cases .....................................13 7.4. AES_192_CM_PRF Test Cases .................................13 8. Acknowledgements ...............................................15 9. References .....................................................15 9.1. Normative References ......................................15 9.2. Informative References ....................................15
This memo describes the use of the Advanced Encryption Standard (AES) [FIPS197] with 192- and 256-bit keys within the Secure RTP (SRTP) protocol [RFC3711]. Below, those block ciphers are referred to as AES-192 and AES-256, respectively, and the use of AES with a 128-bit key is referred to as AES-128. This document describes counter mode encryption for SRTP and SRTCP and appropriate SRTP key derivation functions for AES-192 and AES-256. It also defines new crypto suites that use these new functions.
While AES-128 is widely regarded as more than adequately secure, some users may be motivated to adopt AES-192 or AES-256 due to a perceived need to pursue a highly conservative security strategy. For instance, the Suite B profile requires AES-256 for the protection of TOP SECRET information [suiteB]. (Note that while the AES-192 and AES-256 encryption methods defined in this document use Suite B algorithms, the crypto suites in this document use the HMAC-SHA-1 algorithm, which is not included in Suite B.) See Section 6 for more discussion of security issues.
The crypto functions described in this document are an addition to, and not a replacement for, the crypto functions defined in [RFC3711].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Section 4.1.1 of [RFC3711] defines AES counter mode encryption, which it refers to as AES_CM. This definition applies to all of the AES key sizes. In this note, AES-192 counter mode and AES-256 counter mode and are denoted as AES_192_CM and AES_256_CM, respectively. In both of these ciphers, the plaintext inputs to the block cipher are formed as in AES_CM, and the block cipher outputs are processed as in AES_CM. The only difference in the processing is that AES_192_CM uses AES-192, and AES_256_CM uses AES-256. Both AES_192_CM and AES_256_CM use a 112-bit salt as an input, as does AES_CM.
For the convenience of the reader, the structure of the counter blocks in SRTP counter mode encryption is illustrated in Figure 1, using the terminology from Section 4.1.1 of [RFC3711]. In this diagram, the symbol (+) denotes the bitwise exclusive-or operation, and the AES encrypt operation uses AES-128, AES-192, or AES-256 for AES_CM, AES_192_CM, and AES_256_CM, respectively. The field labeled
McGrew Standards Track [Page 3]
RFC 6188 SRTP AES-192 and AES-256 March 2011
b_c contains a block counter, the value of which increments once for each invocation of the "AES Encrypt" function. The SSRC field is part of the RTP header [RFC3550].
3. The AES_192_CM_PRF and AES_256_CM_PRF Key Derivation Functions
Section 4.3.3 of [RFC3711] defines an AES counter mode key derivation function, which it refers to as AES_CM PRF (and sometimes as AES-CM PRF). (That specification uses the term PRF, or pseudo-random function, interchangeably with the phrase "key derivation function".) This key derivation function can be used with any AES key size. In this note, the AES-192 counter mode PRF and AES-256 counter mode PRF are denoted as AES_192_CM_PRF and AES_256_CM_PRF, respectively. In both of these PRFs, the plaintext inputs to the block cipher are formed as in the AES_CM PRF, and the block cipher outputs are processed as in the AES_CM PRF. The only difference in the processing is that AES_192_CM_PRF uses AES-192, and AES_256_CM_PRF uses AES-256. Both AES_192_CM_PRF and AES_256_CM_PRF use a 112-bit salt as an input, as does the AES_CM PRF.
For the convenience of the reader, the structure of the counter blocks in SRTP counter mode key derivation is illustrated in Figure 2, using the terminology from Section 4.3.3 of [RFC3711]. In this diagram, the symbol (+) denotes the bitwise exclusive-or operation, and the "AES Encrypt" operation uses AES-128, AES-192, or AES-256 for the AES_CM PRF, AES_192_CM_PRF, and AES_256_CM_PRF,
McGrew Standards Track [Page 4]
RFC 6188 SRTP AES-192 and AES-256 March 2011
respectively. The field "LB" contains the 8-bit constant "label", which is provided as an input to the key derivation function (and which is distinct for each type of key generated by that function). The field labeled b_c contains a block counter, the value of which increments once for each invocation of the "AES Encrypt" function. The DIV operation is defined in Section 4.3.1 of [RFC3711] as follows. Let "a DIV t" denote integer division of a by t, rounded down, and with the convention that "a DIV 0 = 0" for all a. We also make the convention of treating "a DIV t" as a bit string of the same length as a, and thus "a DIV t" will, in general, have leading zeros.
one octet <--> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |00|00|00|00|00|00|00|LB| index DIV kdr | b_c |---+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ v | master salt |00|00|->(+) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | v +-------------+ master key -> | AES encrypt | +-------------+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | output block |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: The AES Counter Mode Key Derivation Function
When AES_192_CM is used for encryption, AES_192_CM_PRF SHOULD be used as the key derivation function, and AES_128_CM_PRF MUST NOT be used as the key derivation function.
When AES_256_CM is used for encryption, AES_256_CM_PRF SHOULD be used as the key derivation function. Both AES_128_CM_PRF and AES_192_CM_PRF MUST NOT be used as the key derivation function.
AES_256_CM_PRF MAY be used as the key derivation function when AES_CM is used for encryption, and when AES_192_CM is used for encryption. AES_192_CM_PRF MAY be used as the key derivation function when AES_CM is used for encryption.
McGrew Standards Track [Page 5]
RFC 6188 SRTP AES-192 and AES-256 March 2011
Rationale: it is essential that the cryptographic strength of the key derivation meets or exceeds that of the encryption method. It is natural to use the same function for both encryption and key derivation. However, it is not required to do so because it is desirable to allow these ciphers to be used with alternative key derivation functions that may be defined in the future.
This section defines SRTP crypto suites that use the ciphers and key derivation functions defined in this document. The parameters in these crypto suites are described in Section 8.2 of [RFC3711]. These suites are registered with IANA for use with the SDP Security Descriptions attributes (Section 10.3.2.1 of [RFC4568]). Other SRTP key management methods that use the crypto functions defined in this document are encouraged to also use these crypto suite definitions.
Rationale: the crypto suites use the same authentication function that is mandatory to implement in SRTP, HMAC-SHA1 with a 160-bit key. HMAC-SHA1 would accept larger key sizes, but when it is used with keys larger than 160 bits, it does not provide resistance to cryptanalysis greater than that security level, because it has only 160 bits of internal state. By retaining 160-bit authentication keys, the crypto suites in this note have more compatibility with existing crypto suites and implementations of them.
AES-128 provides a level of security that is widely regarded as being more than sufficient for providing confidentiality. It is believed that the economic cost of breaking AES-128 is significantly higher than the cost of more direct approaches to violating system security, e.g., theft, bribery, wiretapping, and other forms of malfeasance.
Future advances in state-of-the art cryptanalysis could eliminate this confidence in AES-128, and motivate the use of AES-192 or AES- 256. AES-192 is regarded as being secure even against some adversaries for which breaking AES-128 may be feasible. Similarly, AES-256 is regarded as being secure even against some adversaries for which it may be feasible to break AES-192. The availability of the larger key size versions of AES provides a fallback plan in case of unanticipated cryptanalytic results.
It is conjectured that AES-256 provides adequate security even against adversaries that possess the ability to construct a quantum computer that works on 256 or more quantum bits. No such computer is known to exist; its feasibility is an area of active speculation and research.
Despite the apparent sufficiency of AES-128, some users are interested in the larger AES key sizes. For some applications, the 40% increase in computational cost for AES-256 over AES-128 is a worthwhile bargain when traded for the security advantages outlined above. These applications include those with a perceived need for very high security, e.g., due to a desire for very long-term confidentiality.
AES-256 (as it is used in this note) provides the highest level of security, and it SHOULD be used whenever the highest possible security is desired. AES-192 provides a middle ground between the
McGrew Standards Track [Page 9]
RFC 6188 SRTP AES-192 and AES-256 March 2011
128-bit and 256-bit versions of AES, and it MAY be used when security higher than that of AES-128 is desired. In this note, AES-192 and AES-256 are used with keys that are generated via a strong pseudo- random source, and thus the related-key attacks that have been described in the theoretical literature are not applicable.
As with any cipher, the conjectured security level of AES may change over time. The considerations in this section reflect the best knowledge available at the time of publication of this document.
It is desirable that AES_192_CM and AES_192_CM_PRF be used with an authentication function that uses a 192-bit key, and that AES_256_CM and AES_256_CM_PRF be used with an authentication function that uses a 256-bit key. However, this desire is not regarded as security critical. Cryptographic authentication is resilient against future advances in cryptanalysis, since the opportunity for a forgery attack against a session closes when that session closes. For this reason, this note defines new ciphers, but not new authentication functions.
This section provides test data for the AES_256_CM_PRF key derivation function, which uses AES-256 in counter mode. In the following, we walk through the initial key derivation for the AES-256 counter mode cipher, which requires a 32-octet session encryption key and a 14- octet session salt, and the HMAC-SHA1 authentication function, which requires a 20-octet session authentication key. These values are called the cipher key, the cipher salt, and the auth key in the following. Since this is the initial key derivation and the key derivation rate is equal to zero, the value of (index DIV key_derivation_rate) is zero (actually, a six-octet string of zeros). In the following, we shorten key_derivation_rate to kdr.
The inputs to the key derivation function are the 32-octet master key and the 14-octet master salt:
We first show how the cipher key is generated. The input block for AES-256-CM is generated by exclusive-oring the master salt with the concatenation of the encryption key label 0x00 with (index DIV kdr), then padding on the right with two null octets (which implements the multiply-by-2^16 operation, see Section 4.3.3 of RFC 3711). The resulting value is then AES-256-CM-encrypted using the master key to get the cipher key.
index DIV kdr: 000000000000 label: 00 master salt: 3b04803de51ee7c96423ab5b78d2 ----------------------------------------------- xor: 3b04803de51ee7c96423ab5b78d2 (x, PRF input)
Next, we show how the cipher salt is generated. The input block for AES-256-CM is generated by exclusive-oring the master salt with the concatenation of the encryption salt label. That value is padded and encrypted as above.
McGrew Standards Track [Page 11]
RFC 6188 SRTP AES-192 and AES-256 March 2011
index DIV kdr: 000000000000 label: 02 master salt: 3b04803de51ee7c96423ab5b78d2
Below, the AES-256 output blocks that form the auth key are shown on the left, while the corresponding AES-256 input blocks are shown on the right. Note that the final AES-256 output is truncated to a 4-byte length. The final auth key is shown below.
This section provides test data for the AES_192_CM_PRF key derivation function, which uses AES-192 in counter mode. In the following, we walk through the initial key derivation for the AES-192 counter mode cipher, which requires a 24-octet session encryption key and a 14- octet session salt, and the HMAC-SHA1 authentication function, which requires a 20-octet session authentication key. These values are called the cipher key, the cipher salt, and the auth key in the following. Since this is the initial key derivation and the key derivation rate is equal to zero, the value of (index DIV key_derivation_rate) is zero (actually, a six-octet string of zeros). In the following, we shorten key_derivation_rate to kdr.
The inputs to the key derivation function are the 24-octet master key and the 14-octet master salt:
We first show how the cipher key is generated. The input block for AES-192-CM is generated by exclusive-oring the master salt with the concatenation of the encryption key label 0x00 with (index DIV kdr), then padding on the right with two null octets (which implements the
McGrew Standards Track [Page 13]
RFC 6188 SRTP AES-192 and AES-256 March 2011
multiply-by-2^16 operation, see Section 4.3.3 of RFC 3711). The resulting value is then AES-192-CM encrypted using the master key to get the cipher key.
index DIV kdr: 000000000000 label: 00 master salt: c8522f3acd4ce86d5add78edbb11 ----------------------------------------------- xor: c8522f3acd4ce86d5add78edbb11 (x, PRF input)
Next, we show how the cipher salt is generated. The input block for AES-192-CM is generated by exclusive-oring the master salt with the concatenation of the encryption salt label. That value is padded and encrypted as above.
index DIV kdr: 000000000000 label: 02 master salt: c8522f3acd4ce86d5add78edbb11
Below, the AES-192 output blocks that form the auth key are shown on the left, while the corresponding AES-192 input blocks are shown on the right. Note that the final AES-192 output is truncated to a four-byte length. The final auth key is shown below.
Thanks are due to John Mattsson for verifying the test cases in the document and providing comments, to Bob Bell for feedback and encouragement, and to Richard Barnes and Hilarie Orman for constructive review.
[FIPS197] "The Advanced Encryption Standard (AES)", FIPS-197 Federal Information Processing Standard.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.