draft-ietf-ipsecme-aes-ctr-ikev2-07.txt   rfc5930.txt 
IPSECME S. Shen Internet Engineering Task Force (IETF) S. Shen
Internet-Draft Huawei Request for Comments: 5930 Huawei
Updates: RFC4307 Y. Mao Category: Informational Y. Mao
(if approved) H3C ISSN: 2070-1721 Hangzhou H3C Tech. Co., Ltd.
Intended status: Standards Track NSS. Murthy NSS. Murthy
Expires: October 3, 2010 Freescale Semiconductor Freescale Semiconductor
April 1, 2010 July 2010
Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Using Advanced Encryption Standard Counter Mode (AES-CTR)
draft-ietf-ipsecme-aes-ctr-ikev2-07 with the Internet Key Exchange version 02 (IKEv2) Protocol
Abstract Abstract
This document describes the usage of Advanced Encryption Standard This document describes the usage of Advanced Encryption Standard
Counter Mode (AES-CTR), with an explicit initialization vector, by Counter Mode (AES-CTR), with an explicit Initialization Vector, by
IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting
exchange. the IKEv2 exchanges that follow the IKE_SA_INIT exchange.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on October 3, 2010. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Conventions Used In This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document ..........................3
2. IKEv2 Encrypted Payload . . . . . . . . . . . . . . . . . . . 4 2. IKEv2 Encrypted Payload .........................................3
3. IKEv2 Conventions . . . . . . . . . . . . . . . . . . . . . . 5 3. IKEv2 Conventions ...............................................4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations .........................................4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations .............................................4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments .................................................4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References ......................................................5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References .......................................5
7.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References .....................................5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
IKEv2 [RFC4306] is a component of IPsec used for performing mutual The Internet Key Exchange version 2 (IKEv2) protocol [RFC4306] is a
authentication and establishing and maintaining security associations component of IPsec used for performing mutual authentication and
(SAs). [RFC4307] defines the set of algorithms that are mandatory to establishing and maintaining security associations (SAs). [RFC4307]
implement as part of IKEv2, as well as algorithms that should be defines the set of algorithms that are mandatory to implement as part
implemented because they may be promoted to mandatory at some future of IKEv2, as well as algorithms that should be implemented because
time. [RFC4307] requires that an implementation "SHOULD" support they may be promoted to mandatory at some future time. [RFC4307]
Advanced Encryption Standard [AES] in Counter Mode [MODES] (AES-CTR) requires that an implementation "SHOULD" support Advanced Encryption
as a Transform Type 1 Algorithm (encryption). Standard [AES] Counter Mode [MODES] (AES-CTR) as a Transform Type 1
algorithm (encryption).
Although the [RFC4307] specifies that the AES-CTR encryption Although [RFC4307] specifies that the AES-CTR encryption algorithm
algorithm feature SHOULD be supported by IKEv2, no existing document feature SHOULD be supported by IKEv2, no existing document specifies
specifies how IKEv2 can support the feature. This document provides how IKEv2 can support the feature. This document provides the
the specification and usage of AES-CTR counter mode by IKEv2. specification and usage of AES-CTR Counter Mode by IKEv2.
1.1. Conventions Used In This Document 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. IKEv2 Encrypted Payload 2. IKEv2 Encrypted Payload
Section 3.14 of IKEv2 [RFC4306] explains the IKEv2 Encrypted Payload. Section 3.14 of IKEv2 [RFC4306] explains the IKEv2 Encrypted Payload.
The encrypted Payload, denoted SK{...} contains other IKEv2 payloads The Encrypted Payload, denoted SK{...}, contains other IKEv2 payloads
in encrypted form. in encrypted form.
The payload includes an Initialization Vector (IV) whose length is The payload includes an Initialization Vector (IV) whose length is
defined by the encryption algorithm negotiated. It also includes defined by the encryption algorithm negotiated. It also includes
Integrity Checksum data. These two fields are not encrypted. Integrity Checksum data. These two fields are not encrypted.
The IV field MUST be 8 octets when the AES-CTR algorithm is used for The IV field MUST be 8 octets when the AES-CTR algorithm is used for
IKEv2 encryption. The requirements for this IV are same as what is IKEv2 encryption. The requirements for this IV are the same as what
specified for ESP in Section 3.1 of [RFC3686]. is specified for the Encapsulating Security Payload (ESP) in
Section 3.1 of [RFC3686].
IKEv2 requires Integrity Check Data for the Encrypted Payload as IKEv2 requires Integrity Check Data for the Encrypted Payload as
described in section 3.14 of [RFC4306]. The choice of integrity described in Section 3.14 of [RFC4306]. The choice of integrity
algorithms in IKEv2 is defined in [RFC4307] or its future update algorithms in IKEv2 is defined in [RFC4307] or documents that update
documents. it in the future.
When AES-CTR is used in IKEv2, no padding is required. The Padding 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 of the Encrypted Payload SHOULD be empty, and the Pad Length
field SHOULD be zero. However, according to [RFC4306], the recipient field SHOULD be zero. However, according to [RFC4306], the recipient
MUST accept any length that results in proper alignment. It should MUST accept any length that results in proper alignment. It should
be noted that the ESP [RFC4303] Encrypted Payload requires alignment be noted that the ESP [RFC4303] Encrypted Payload requires alignment
on a 4-byte boundary while the IKEv2 [RFC4306] Encrypted Payload does on a 4-byte boundary while the IKEv2 [RFC4306] Encrypted Payload does
not have such a requirement. not have such a requirement.
The Encrypted Payload is the XOR of the plaintext and key stream. The Encrypted Payload is the XOR of the plaintext and key stream.
The key stream is generated by inputting Counter Blocks into the AES The key stream is generated by inputting counter blocks into the AES
algorithm. The AES counter block is 128 bits including 4 octets algorithm. The AES counter block is 128 bits, including a 4-octet
nonce, 8 octets Initialization Vector and 4 octets Block counter in Nonce, 8-octet Initialization Vector, and 4-octet Block Counter, in
order. The block counter begins with the value of one and increments that order. The Block Counter begins with the value of one and
by one to generate next portion of the key stream. The detailed increments by one to generate the next portion of the key stream.
requirements for the counter block is the same as what is specified The detailed requirements for the counter block are the same as those
in Section 4 of [RFC3686]. specified in Section 4 of [RFC3686].
3. IKEv2 Conventions 3. IKEv2 Conventions
The use of AES-CTR for the IKE SA is negotiated in the same way as 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 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 key length transform attribute is used in the same way; and the
keying material (consisting of the actual key and the nonce) is keying material (consisting of the actual key and the nonce) is
derived in the same way. Check Section 5 of [RFC3686] for the derived in the same way. See Section 5 of [RFC3686] for detailed
detailed descriptions. descriptions.
4. Security Considerations 4. Security Considerations
Security considerations explained in section 7 of [RFC3686] are Security considerations explained in Section 7 of [RFC3686] are
entirely relevant for this draft also. The security considerations entirely relevant to this document as well. The security
on fresh keys and integrity protection in section 7 of [RFC3686] are considerations on fresh keys and integrity protection in Section 7 of
totally applicable on using AES-CTR in IKEv2; see [RFC3686] for [RFC3686] are totally applicable to using AES-CTR in IKEv2; see
details. As static keys are never used in IKEv2 for IKE_SA and [RFC3686] for details. As static keys are never used in IKEv2 for
integrity protection is mandatory for IKE_SA, these issues are not IKE_SA and integrity protection is mandatory for IKE_SA, these issues
applicable for AES-CTR in IKEv2 when protecting IKE_SA. are not applicable for AES-CTR in IKEv2 when protecting IKE_SA.
Additionally, since AES has a 128-bit block size, regardless of the Additionally, since AES has a 128-bit block size, regardless of the
mode employed, the ciphertext generated by AES encryption becomes mode employed, the ciphertext generated by AES encryption becomes
distinguishable from random values after 2^64 blocks are encrypted distinguishable from random values after 2^64 blocks are encrypted
with a single key. Since IKEv2 SA cannot carry that much of data with a single key. Since IKEv2 SA cannot carry that much data
(because of the size limit of message ID of IKEv2 message and the (because of the size limit of the message ID of the IKEv2 message and
requirements for the message ID in Section 4 of [RFC4306] ), this the requirements for the message ID in Section 4 of [RFC4306]), this
issue is not a concern here. issue is not a concern here.
For generic attacks on AES, such as brute force or precalculations, For generic attacks on AES, such as brute force or precalculations,
the requirement of key size provides reasonable security the key-size requirements provide reasonable security
[Recommendations]. [Recommendations].
5. IANA Considerations 5. IANA Considerations
IANA [IANA-Para] has assigned an Encryption Transform ID for AES-CTR IANA [IANA-Para] has assigned an Encryption Algorithm Transform ID
encryption with an explicit IV for IKEv2: 13 as the number and for AES-CTR encryption with an explicit IV for IKEv2: 13 as the
ENCR_AES_CTR as the name. IANA is asked to add a reference to this number, and ENCR_AES_CTR as the name. IANA has added a reference to
RFC in that entry. this RFC in that entry.
6. Acknowledgments 6. Acknowledgments
The authors thank Yaron Sheffer, Paul Hoffman, Tero Kivinen and The authors thank Yaron Sheffer, Paul Hoffman, Tero Kivinen, and
Alfred Hoenes for their direction and comments on this document. Alfred Hoenes for their direction and comments on this document.
This document specifies usage of AES-CTR with IKEv2, similarly as This document specifies usage of AES-CTR with IKEv2, similar to usage
usage of AES-CTR with ESP as specified in [RFC3686]. [RFC3686] is of AES-CTR with ESP as specified in [RFC3686]. The reader is
referred for the same descriptions and definitions. The authors referred to [RFC3686] for the same descriptions and definitions. The
thank Russ Housley for providing the document. authors thank Russ Housley for providing the document.
During the production and modification of this document, both Huawei During the production and modification of this document, both Huawei
and CNNIC supported one of the author, Sean Shen. Both are and CNNIC supported one of the authors, Sean Shen. Both are
appreciated as affiliations of the author. appreciated as affiliations of the author.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC 4306, December 2005. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC3686] Housley, R., "Using Advanced Encryption Standard
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, (AES) Counter Mode With IPsec Encapsulating
December 2005. Security Payload (ESP)", RFC 3686, January 2004.
[AES] National Institute of Standards and Technology, "Advanced [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2)
Encryption Standard (AES)", FIPS PUB 197, November 2001, < Protocol", RFC 4306, December 2005.
http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>.
[IANA-Para] [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in
Internet Assigned Numbers Authority, "Internet Key the Internet Key Exchange Version 2 (IKEv2)",
Exchange Version 2 (IKEv2) Parameters", September 2009, RFC 4307, December 2005.
<http://www.iana.org/assignments/ikev2-parameters>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of [AES] National Institute of Standards and Technology,
Operation Methods and Techniques", NIST Special "Advanced Encryption Standard (AES)", FIPS PUB 197,
Publication 800-38A, December 2001, <http://csrc.nist.gov/ November 2001, <http://csrc.nist.gov/
publications/nistpubs/800-38a/sp800-38a.pdf>. publications/fips/fips197/fips-197.pdf>.
7.2. Informative References [IANA-Para] Internet Assigned Numbers Authority, "Internet Key
Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [MODES] Dworkin, M., "Recommendation for Block Cipher Modes
Requirement Levels", BCP 14, RFC 2119, March 1997. of Operation -- Methods and Techniques", NIST
Special Publication 800-38A, December 2001,
<http://csrc.nist.gov/publications/nistpubs/
800-38a/sp800-38a.pdf>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 7.2. Informative References
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload
RFC 4303, December 2005. (ESP)", RFC 4303, December 2005.
[Recommendations] [Recommendations] Barker, E., Barker, W., Burr, W., Polk, W., and M.
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, Smid, "Recommendation for Key Management - Part 1:
"Recommendation for Key Management - Part1 - General General (Revised)", NIST Special
(Revised)", NIST Special Publication 800-57, March 2007, < Publication 800-57, March 2007, <http://
http://csrc.nist.gov/publications/nistpubs/800-57/ csrc.nist.gov/publications/nistpubs/800-57/
SP800-57-Part1.pdf>. sp800-57-Part1-revised2_Mar08-2007.pdf>.
Authors' Addresses Authors' Addresses
Sean Shen Sean Shen
Huawei Huawei
4, South 4th Street, Zhongguancun 4, South 4th Street, Zhongguancun
Beijing 100190 Beijing 100190
China China
Email: shenshuo@cnnic.cn EMail: shenshuo@cnnic.cn
Yu Mao Yu Mao
H3C Tech. Co., Ltd Hangzhou H3C Tech. Co., Ltd.
Oriental Electronic Bld. Oriental Electronic Bld., No. 2
No.2 Chuangye Road Chuangye Road
Shang-Di Information Industry Shang-Di Information Industry
Hai-Dian District Hai-Dian District
Beijing 100085 Beijing 100085
China China
Email: yumao9@gmail.com EMail: yumao9@gmail.com
N S Srinivasa Murthy N S Srinivasa Murthy
Freescale Semiconductor Freescale Semiconductor
UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA
HYDERABAD 500082 HYDERABAD 500082
INDIA INDIA
Email: ssmurthy.nittala@freescale.com EMail: ssmurthy.nittala@freescale.com
 End of changes. 39 change blocks. 
129 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/