AES-CTR for IKEv2: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
A fast encryption method for protecting IKEv2 key exchange messages
Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol", RFC 5930, DOI 10.17487/RFC5930, July 2010, <https://www.rfc-editor.org/info/rfc5930>.
@misc{rfc5930,
series = {Request for Comments},
number = 5930,
howpublished = {RFC 5930},
publisher = {RFC Editor},
doi = {10.17487/RFC5930},
url = {https://www.rfc-editor.org/info/rfc5930},
author = {S. Shen and Y. Mao and NSS. Murthy},
title = {{Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol}},
pagetotal = 6,
year = 2010,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Shen
Request for Comments: 5930 Huawei
Category: Informational Y. Mao
ISSN: 2070-1721 Hangzhou H3C Tech. Co., Ltd.
NSS. Murthy
Freescale Semiconductor
July 2010
Using Advanced Encryption Standard Counter Mode (AES-CTR)
with the Internet Key Exchange version 02 (IKEv2) Protocol
Abstract
This document describes the usage of Advanced Encryption Standard
Counter Mode (AES-CTR), with an explicit Initialization Vector, by
the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting
the IKEv2 exchanges that follow the IKE_SA_INIT exchange.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see 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/rfc5930.
Copyright Notice
Copyright (c) 2010 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.
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. IKEv2 Encrypted Payload .........................................3
3. IKEv2 Conventions ...............................................4
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. Acknowledgments .................................................4
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................5
1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol [RFC4306] is a
component of IPsec used for performing mutual authentication and
establishing and maintaining security associations (SAs). [RFC4307]
defines the set of algorithms that are mandatory to implement as part
of IKEv2, as well as algorithms that should be implemented because
they may be promoted to mandatory at some future time. [RFC4307]
requires that an implementation "SHOULD" support Advanced Encryption
Standard [AES] Counter Mode [MODES] (AES-CTR) as a Transform Type 1
algorithm (encryption).
Although [RFC4307] specifies that the AES-CTR encryption algorithm
feature SHOULD be supported by IKEv2, no existing document specifies
how IKEv2 can support the feature. This document provides the
specification and usage of AES-CTR Counter Mode by IKEv2.
Implementers need to carefully consider the use of AES-CTR over the
mandatory-to-implement algorithms in [RFC4307], because the
performance improvements of AES-CTR are minimal in the context of
IKEv2. Furthermore, these performance improvements may be offset by
the Counter Mode specific risk of a minor, hard-to-detect
implementation issue resulting in total security failure.
1.1. Conventions Used in This Document
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].
2. IKEv2 Encrypted Payload
Section 3.14 of IKEv2 [RFC4306] explains the IKEv2 Encrypted Payload.
The Encrypted Payload, denoted SK{...}, contains other IKEv2 payloads
in encrypted form.
The payload includes an Initialization Vector (IV) whose length is
defined by the encryption algorithm negotiated. It also includes
Integrity Checksum data. These two fields are not encrypted.
The IV field MUST be 8 octets when the AES-CTR algorithm is used for
IKEv2 encryption. The requirements for this IV are the same as what
is specified for the Encapsulating Security Payload (ESP) in
Section 3.1 of [RFC3686].
IKEv2 requires Integrity Check Data for the Encrypted Payload as
described in Section 3.14 of [RFC4306]. The choice of integrity
algorithms in IKEv2 is defined in [RFC4307] or documents that update
it in the future.
When AES-CTR is used in IKEv2, no padding is required. The Padding
field of the Encrypted Payload SHOULD be empty, and the Pad Length
field SHOULD be zero. However, according to [RFC4306], the recipient
MUST accept any length that results in proper alignment. It should
be noted that the ESP [RFC4303] Encrypted Payload requires alignment
on a 4-byte boundary while the IKEv2 [RFC4306] Encrypted Payload does
not have such a requirement.
The Encrypted Payload is the XOR of the plaintext and key stream.
The key stream is generated by inputting counter blocks into the AES
algorithm. The AES counter block is 128 bits, including a 4-octet
Nonce, 8-octet Initialization Vector, and 4-octet Block Counter, in
that order. The Block Counter begins with the value of one and
increments by one to generate the next portion of the key stream.
The detailed requirements for the counter block are the same as those
specified in Section 4 of [RFC3686].
3. IKEv2 Conventions
The use of AES-CTR for the IKE SA is negotiated in the same way as
AES-CTR for ESP. The Transform ID (ENCR_AES_CTR) is the same; the
key length transform attribute is used in the same way; and the
keying material (consisting of the actual key and the nonce) is
derived in the same way. See Section 5 of [RFC3686] for detailed
descriptions.
4. Security Considerations
Security considerations explained in Section 7 of [RFC3686] are
entirely relevant to this document as well. The security
considerations on fresh keys and integrity protection in Section 7 of
[RFC3686] are totally applicable to using AES-CTR in IKEv2; see
[RFC3686] for details. As static keys are never used in IKEv2 for
IKE_SA and integrity protection is mandatory for IKE_SA, these issues
are not applicable for AES-CTR in IKEv2 when protecting IKE_SA.
Additionally, since AES has a 128-bit block size, regardless of the
mode employed, the ciphertext generated by AES encryption becomes
distinguishable from random values after 2^64 blocks are encrypted
with a single key. Since IKEv2 SA cannot carry that much data
(because of the size limit of the message ID of the IKEv2 message and
the requirements for the message ID in Section 4 of [RFC4306]), this
issue is not a concern here.
For generic attacks on AES, such as brute force or precalculations,
the key-size requirements provide reasonable security
[Recommendations].
5. IANA Considerations
IANA [IANA-Para] has assigned an Encryption Algorithm Transform ID
for AES-CTR encryption with an explicit IV for IKEv2: 13 as the
number, and ENCR_AES_CTR as the name. IANA has added a reference to
this RFC in that entry.
6. Acknowledgments
The authors thank Yaron Sheffer, Paul Hoffman, Tero Kivinen, and
Alfred Hoenes for their direction and comments on this document.
This document specifies usage of AES-CTR with IKEv2, similar to usage
of AES-CTR with ESP as specified in [RFC3686]. The reader is
referred to [RFC3686] for the same descriptions and definitions. The
authors thank Russ Housley for providing the document.
During the production and modification of this document, both Huawei
and CNNIC supported one of the authors, Sean Shen. Both are
appreciated as affiliations of the author.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3686] Housley, R., "Using Advanced Encryption Standard
(AES) Counter Mode With IPsec Encapsulating
Security Payload (ESP)", RFC 3686, January 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in
the Internet Key Exchange Version 2 (IKEv2)",
RFC 4307, December 2005.
[AES] National Institute of Standards and Technology,
"Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001, <http://csrc.nist.gov/
publications/fips/fips197/fips-197.pdf>.
[IANA-Para] Internet Assigned Numbers Authority, "Internet Key
Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes
of Operation -- Methods and Techniques", NIST
Special Publication 800-38A, December 2001,
<http://csrc.nist.gov/publications/nistpubs/
800-38a/sp800-38a.pdf>.
7.2. Informative References
[RFC4303] Kent, S., "IP Encapsulating Security Payload
(ESP)", RFC 4303, December 2005.
[Recommendations] Barker, E., Barker, W., Burr, W., Polk, W., and M.
Smid, "Recommendation for Key Management - Part 1:
General (Revised)", NIST Special
Publication 800-57, March 2007, <http://
csrc.nist.gov/publications/nistpubs/800-57/
sp800-57-Part1-revised2_Mar08-2007.pdf>.
Authors' Addresses
Sean Shen
Huawei
4, South 4th Street, Zhongguancun
Beijing 100190
China
EMail: shenshuo@cnnic.cn
Yu Mao
Hangzhou H3C Tech. Co., Ltd.
Oriental Electronic Bld., No. 2
Chuangye Road
Shang-Di Information Industry
Hai-Dian District
Beijing 100085
China
EMail: yumao9@gmail.com
N S Srinivasa Murthy
Freescale Semiconductor
UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA
HYDERABAD 500082
INDIA
EMail: ssmurthy.nittala@freescale.com
AI ELI5
On this page
§1What AES-CTR is and Why It Matters
RFC 5930 explains how to use AES Counter Mode (AES-CTR) with IKEv2, the protocol that sets up and manages IPsec security associations. IKEv2 is how two systems negotiate encryption keys and agree on how to protect their traffic.
AES-CTR is an encryption mode where the AES algorithm generates a stream of random-looking bytes, which are mixed with the plaintext message to encrypt it. This differs from block cipher modes that encrypt fixed-size blocks at a time. RFC 4307 recommended that IKEv2 implementations SHOULD support AES-CTR, but no document explained how to do it. This RFC fills that gap.
The main advantage is speed: counter mode can encrypt data faster than some other modes, and it does not require padding. However, counter mode also carries specific security risks if implemented incorrectly, so implementers must understand those risks before deploying it.
IKEv2 is how two computers agree on secret codes to protect their messages. AES-CTR is a way to scramble information super fast using a counter that generates new encryption bytes for each part of the message. This RFC says how to do that safely.
§2The Encrypted Payload Structure
When AES-CTR is used in IKEv2, it encrypts the payload (the message content) following the initial IKE_SA_INIT exchange. The encrypted payload contains two unencrypted fields and one encrypted section.
The initialization vector (IV), which must be 8 octets (bytes) when using AES-CTR, is sent in the clear. The IV is a starting value that ensures each message produces different ciphertext even with the same key. The integrity checksum data is also unencrypted, allowing the receiver to verify the message was not tampered with in transit. Both of these fields are required by IKEv2 regardless of the encryption method used.
When AES-CTR is used, the RFC specifies that no padding should be added to the encrypted data, and the Pad Length field should be zero. The receiver must still accept any padding that results in proper alignment, as allowed by RFC 4306, but under normal circumstances padding is unnecessary.
The message starts with a fresh starting number (the IV) and a checking number, both sent openly. Then the secret part gets scrambled using AES-CTR, with no need to add extra filler bytes at the end.
§3How the Counter Block Works
At the heart of AES-CTR is the counter block, a 128-bit structure that AES processes to generate the encryption stream. The counter block has three parts: a 4-octet (32-bit) nonce derived from the key material, the 8-octet IV, and a 4-octet block counter that starts at one and increments by one for each block.
To encrypt a message, the counter block is fed into the AES algorithm repeatedly. The first iteration uses counter value 1, the second uses counter value 2, and so on. Each iteration produces 128 bits of key stream. These key stream blocks are XORed with the plaintext to produce the ciphertext. To decrypt, the same process is repeated to regenerate the key stream, which is XORed with the ciphertext to recover the plaintext.
This design has the advantage that encryption and decryption are identical operations, and no padding is needed because the key stream is arbitrary in length. However, it also means that reusing the same nonce and IV with the same key would produce identical key streams and completely compromise security, so implementations must ensure the IV is never repeated with the same key.
The counter is like a music box that plays 128 bits of encryption music each time you turn the crank. You start at position 1, then 2, then 3, and so on. Each output gets mixed with the message to scramble it. If you ever use the same starting point twice with the same key, someone can figure out your secrets.
§4Negotiation and Setup
The use of AES-CTR with IKEv2 is negotiated in the same way as AES-CTR with ESP (the Encapsulating Security Payload). During the IKEv2 handshake, the two endpoints exchange proposals of which algorithms they support. If both support AES-CTR (identified by the Transform ID ENCR_AES_CTR, which IANA assigned the value 13), it can be selected.
Once AES-CTR is negotiated, the key material is derived in the same way as for AES-CTR in ESP. The key material contains both the actual encryption key (which can be 128, 192, or 256 bits depending on the key size agreed upon) and the nonce value mentioned above. Both are derived from the shared secret using the negotiated pseudo-random function.
When two computers talk to set up IKEv2, they tell each other which encryption methods they can use. If both say yes to AES-CTR (method number 13), they pick it and generate the actual keys and numbers needed.
§5Security Concerns
The RFC emphasizes that security considerations from RFC 3686 (which specifies AES-CTR for ESP) apply directly to AES-CTR in IKEv2. The most critical concern is that AES has a 128-bit block size. After 2^64 blocks are encrypted with a single key, the ciphertext becomes statistically distinguishable from random. However, IKEv2 security associations cannot carry enough data to reach this limit because of message ID constraints, so this theoretical risk does not apply in practice.
Integrity protection is mandatory for IKEv2 security associations, and IKEv2 never reuses static keys. These properties mean that several risks inherent to counter mode in other contexts (static key reuse, lack of integrity) are mitigated. The implementer's responsibility is to never reuse the same IV with the same key and to correctly implement the counter block structure.
The RFC also notes that performance improvements from AES-CTR in the context of IKEv2 are minimal compared to the mandatory-to-implement algorithms, so the choice to deploy it should be made carefully.
The biggest danger is using the same starting point twice—that breaks everything. But IKEv2 is designed so that never happens. Using AES-CTR may not even make things much faster than the standard methods, so you should think hard before using it.