IPSECME NSS Murthy Internet-Draft Freescale Intended status: Standard Track S.Shen Expires: January 11, 2010 Huawei Y.Mao H3C July 10, 2009 Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 draft-ipsecme-aes-ctr-ikev2-00 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 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 11, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting IKE-SA and Child-SA negotiations. Shen, et al. Expires January 11, 2010 [Page 1] Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. AES Counter Mode . . . . . . . . . . . . . . . . . . . . . . . 3 3. IKEv2 Encrypted Payload . . .. . . . . . . . . . . . . . . . . 3 3.1 Initialization Vector(IV). . . . . . . . . . . . . . . . . . 4 3.2 Integrity Checksum Data . . . . . . . . . . . . . . . . . . 4 4. Counter Block Format. . . . . . . . . . . . . . . . . . . . . . 5 5 IKEv2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5 5.1 Keying Material and Nonces. . . . . . . . . . . . . . . . . . 5 5.2 Encryption identifier. . . . . . . . . . . . . . . . . . . . 6 5.3 Key Length Attribute . . . .. ... . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Shen, et al. Expires January 11, 2010 [Page 2] Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009 1. Introduction All the IKEv2 messages that follow the initial exchange(IKE_SA_INIT) are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKEv2 exchange.These subsequent messages use the syntax of the IKEv2 Encrypted Payload as explained in RFC 4306. This document explains how IKEv2 makes use of AES-CTR algorithm for encrypting IKE messages that follow initial exchange.This document specifies the IANA defined encryption identifier for AES-CTR to be used during IKE-SA and Child-SA negotiations.It explains how to derive the AES-CTR encryption key and nonce required from the key material generated.It also explains the Initialization vector,its length and its uniqueness for a given encryption key.This document explains the counter block format used for encryption and decryption.It provides references for more details regarding implementation of AES-CTR algorithm. 2. AES Counter Mode Section 2 of RFC 3686 provides a description of AES-CTR mode including its characteristics and implementation issues. 3.IKEv2 Encrypted Payload Section 3.14 of IKEv2 RFC 4306 explains the IKEv2 Encrypted Pay load. The encrypted Payload,denoted SK{...} contains other IKEv2 payloads in encrypted form. The pay load 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. 3.1.Initialization Vector(IV) The IV field MUST be eight octets when AES-CTR algorithm is used for encryption.The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is NOT used more than once with a given encryption key.The encryptor can generate the IV in any manner that ensures uniqueness.Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). Shen, et al. Expires January 11, 2010 [Page 3] Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009 3.2.Integrity Checksum Data Since it is trivial to construct a forgery AES-CTR ciphertext from a valid AES-CTR ciphertext, IKEv2 MUST employ an integrity algorithm when AES-CTR is selected for encrypting the IKEv2 payloads. HMAC-SHA-1-96 [HMAC-SHA] is a likely choice. 4.Counter Block Format All the IKEv2 messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKEv2 exchange.These subsequent messages use the syntax of the IKEv2 Encrypted Payload. All such messages carry the IV that is necessary to construct the sequence of counter blocks used to generate the key stream necessary to decrypt the payload.The AES counter block cipher block is 128 bits. Figure 1 shows the format of the counter block. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector (IV) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Counter Block Format The components of the counter block are as follows: Nonce The Nonce field is 4 octets.An unpredictably fresh nonce value MUST be assigned to each security association immediately after it is established.Section 5.1 explains how IKEv2 is used to generate the nonce by the two parties individually. Shen, et al. Expires January 11, 2010 [Page 4] Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009 Initialization Vector The IV field is 64 bits.The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given encryption key.The encryptor includes the IV in the IKEv2 message containing encrypted pay loads. Block Counter The block counter field is the least significant 32 bits of the counter block.The block counter begins with the value of one, and it is incremented to generate subsequent portions of the key stream. The block counter is a 32-bit big-endian integer value. Section 2 provides references to other documents for implementing AES-CTR encryption/decryption process. 5 IKEv2 Conventions This section describes the conventions used by Internet Key Exchange IKEv2 protocol to generate keying material and nonces for use with AES-CTR algorithm for both IKE-SA and Childs-SA negotiations.The identifiers and attributes needed to negotiate security associations which uses AES-CTR are also defined. 5.1 Keying Material and Nonces As we MUST not reuse the same combination of IV and encryption key values with AES-CTR algorithm,IKEv2 can be used to establish fresh keys and Nonces. This section describes the conventions for obtaining an unpredictable and secret nonce value and encryption key using IKEv2. IKEv2 makes use of a negotiated pseudo-random function(PRF) for the construction of keying material for all of the cryptographic algorithms used in both the IKE_SA and the CHILD_SAs as explained in sections 2.14 and 2.17 of RFC 4306.Keying material is extracted from the output string without regard to boundaries.The two directions of traffic flow use different keys. The size of the keying material required for AES-CTR algorithm for different key lengths is as follows: AES-CTR with a 128 bit key The key material required for each AES-CTR key is 20 octets.The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the nonce value in the counter block. Shen, et al. Expires January 11, 2010 [Page 5] Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009 AES-CTR with a 192 bit key The key material requested for each AES-CTR key is 28 octets.The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the nonce value in the counter block. AES-CTR with a 256 bit key The key material requested for each AES-CTR key is 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the nonce value in the counter block. 5.2 Encryption identifier IKEv2 uses the IANA allocated encryption identifier of 13 for AES-CTR with an explicit IV (ENCR_AES_CTR 13) for both the IKE-SA and Child-SA negotiations. 5.3 Key Length Attribute Since the AES-CTR algorithm supports three key lengths, the Key Length attribute MUST be specified in both the IKE-SA and Child-SA negotiations.The Key Length attribute MUST have a value of 128,192, or 256. 6. Security Considerations Security considerations explained in section 7 of RFC 3686 are entirely relevant for this draft also. 7. IANA Considerations IANA has assigned 13 as the transform ID for AES-CTR encryption with an explicit IV.This can be used for both IKE_SA and Child-SA negotiations. 8. References [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC3686] R.Housley.,"Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)"RFC 3686 January 2004. [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>. [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation Methods and Techniques", NIST Special Publication 800-38A, December 2001, . Shen, et al. Expires January 11, 2010 [Page 6] Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009 Authors' Addresses N S Srinivasa murthy Freescale Semiconductor UMA PLAZA,NAGRJUNA CIRCLE,PUNJAGUTTA HYDERABAD 500082 INDIA Email: ssmurthy.nittala@freescale.com Sean Shen Huawei No. 9 Xinxi Road Beijing 100085 China Email: sshen@huawei.com Yu Mao Huawei-3com Email: maoyu@h3c.com Comments are solicited and should be addressed to the working group's mailing list at ipsec@ietf.org and/or the author(s). Shen, et al. Expires January 11, 2010 [Page 7] Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009