idnits 2.17.1 draft-ietf-ipsecme-aes-ctr-ikev2-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 1, 2010) is 5101 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Para' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME S. Shen 3 Internet-Draft Huawei 4 Updates: RFC4307 Y. Mao 5 (if approved) H3C 6 Intended status: Standards Track NSS. Murthy 7 Expires: October 3, 2010 Freescale Semiconductor 8 April 1, 2010 10 Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 11 draft-ietf-ipsecme-aes-ctr-ikev2-07 13 Abstract 15 This document describes the usage of Advanced Encryption Standard 16 Counter Mode (AES-CTR), with an explicit initialization vector, by 17 IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT 18 exchange. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on October 3, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 62 2. IKEv2 Encrypted Payload . . . . . . . . . . . . . . . . . . . 4 63 3. IKEv2 Conventions . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 IKEv2 [RFC4306] is a component of IPsec used for performing mutual 75 authentication and establishing and maintaining security associations 76 (SAs). [RFC4307] defines the set of algorithms that are mandatory to 77 implement as part of IKEv2, as well as algorithms that should be 78 implemented because they may be promoted to mandatory at some future 79 time. [RFC4307] requires that an implementation "SHOULD" support 80 Advanced Encryption Standard [AES] in Counter Mode [MODES] (AES-CTR) 81 as a Transform Type 1 Algorithm (encryption). 83 Although the [RFC4307] specifies that the AES-CTR encryption 84 algorithm feature SHOULD be supported by IKEv2, no existing document 85 specifies how IKEv2 can support the feature. This document provides 86 the specification and usage of AES-CTR counter mode by IKEv2. 88 1.1. Conventions Used In This Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. IKEv2 Encrypted Payload 96 Section 3.14 of IKEv2 [RFC4306] explains the IKEv2 Encrypted Payload. 97 The encrypted Payload, denoted SK{...} contains other IKEv2 payloads 98 in encrypted form. 100 The payload includes an Initialization Vector (IV) whose length is 101 defined by the encryption algorithm negotiated. It also includes 102 Integrity Checksum data. These two fields are not encrypted. 104 The IV field MUST be 8 octets when the AES-CTR algorithm is used for 105 IKEv2 encryption. The requirements for this IV are same as what is 106 specified for ESP in Section 3.1 of [RFC3686]. 108 IKEv2 requires Integrity Check Data for the Encrypted Payload as 109 described in section 3.14 of [RFC4306]. The choice of integrity 110 algorithms in IKEv2 is defined in [RFC4307] or its future update 111 documents. 113 When AES-CTR is used in IKEv2, no padding is required. The Padding 114 field of the Encrypted Payload SHOULD be empty and the Pad Length 115 field SHOULD be zero. However, according to [RFC4306], the recipient 116 MUST accept any length that results in proper alignment. It should 117 be noted that the ESP [RFC4303] Encrypted Payload requires alignment 118 on a 4-byte boundary while the IKEv2 [RFC4306] Encrypted Payload does 119 not have such a requirement. 121 The Encrypted Payload is the XOR of the plaintext and key stream. 122 The key stream is generated by inputting Counter Blocks into the AES 123 algorithm. The AES counter block is 128 bits including 4 octets 124 nonce, 8 octets Initialization Vector and 4 octets Block counter in 125 order. The block counter begins with the value of one and increments 126 by one to generate next portion of the key stream. The detailed 127 requirements for the counter block is the same as what is specified 128 in Section 4 of [RFC3686]. 130 3. IKEv2 Conventions 132 The use of AES-CTR for the IKE SA is negotiated in the same way as 133 AES-CTR for ESP. The Transform ID (ENCR_AES_CTR) is the same; the 134 key length transform attribute is used in the same way; and the 135 keying material (consisting of the actual key and the nonce) is 136 derived in the same way. Check Section 5 of [RFC3686] for the 137 detailed descriptions. 139 4. Security Considerations 141 Security considerations explained in section 7 of [RFC3686] are 142 entirely relevant for this draft also. The security considerations 143 on fresh keys and integrity protection in section 7 of [RFC3686] are 144 totally applicable on using AES-CTR in IKEv2; see [RFC3686] for 145 details. As static keys are never used in IKEv2 for IKE_SA and 146 integrity protection is mandatory for IKE_SA, these issues are not 147 applicable for AES-CTR in IKEv2 when protecting IKE_SA. 149 Additionally, since AES has a 128-bit block size, regardless of the 150 mode employed, the ciphertext generated by AES encryption becomes 151 distinguishable from random values after 2^64 blocks are encrypted 152 with a single key. Since IKEv2 SA cannot carry that much of data 153 (because of the size limit of message ID of IKEv2 message and the 154 requirements for the message ID in Section 4 of [RFC4306] ), this 155 issue is not a concern here. 157 For generic attacks on AES, such as brute force or precalculations, 158 the requirement of key size provides reasonable security 159 [Recommendations]. 161 5. IANA Considerations 163 IANA [IANA-Para] has assigned an Encryption Transform ID for AES-CTR 164 encryption with an explicit IV for IKEv2: 13 as the number and 165 ENCR_AES_CTR as the name. IANA is asked to add a reference to this 166 RFC in that entry. 168 6. Acknowledgments 170 The authors thank Yaron Sheffer, Paul Hoffman, Tero Kivinen and 171 Alfred Hoenes for their direction and comments on this document. 173 This document specifies usage of AES-CTR with IKEv2, similarly as 174 usage of AES-CTR with ESP as specified in [RFC3686]. [RFC3686] is 175 referred for the same descriptions and definitions. The authors 176 thank Russ Housley for providing the document. 178 During the production and modification of this document, both Huawei 179 and CNNIC supported one of the author, Sean Shen. Both are 180 appreciated as affiliations of the author. 182 7. References 184 7.1. Normative References 186 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 187 RFC 4306, December 2005. 189 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 190 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 191 December 2005. 193 [AES] National Institute of Standards and Technology, "Advanced 194 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 195 http://csrc.nist.gov/publications/fips/fips197/ 196 fips-197.pdf>. 198 [IANA-Para] 199 Internet Assigned Numbers Authority, "Internet Key 200 Exchange Version 2 (IKEv2) Parameters", September 2009, 201 . 203 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of 204 Operation Methods and Techniques", NIST Special 205 Publication 800-38A, December 2001, . 208 7.2. Informative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, March 1997. 213 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 214 Counter Mode With IPsec Encapsulating Security Payload 215 (ESP)", RFC 3686, January 2004. 217 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 218 RFC 4303, December 2005. 220 [Recommendations] 221 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 222 "Recommendation for Key Management - Part1 - General 223 (Revised)", NIST Special Publication 800-57, March 2007, < 224 http://csrc.nist.gov/publications/nistpubs/800-57/ 225 SP800-57-Part1.pdf>. 227 Authors' Addresses 229 Sean Shen 230 Huawei 231 4, South 4th Street, Zhongguancun 232 Beijing 100190 233 China 235 Email: shenshuo@cnnic.cn 237 Yu Mao 238 H3C Tech. Co., Ltd 239 Oriental Electronic Bld. 240 No.2 Chuangye Road 241 Shang-Di Information Industry 242 Hai-Dian District 243 Beijing 100085 244 China 246 Email: yumao9@gmail.com 248 N S Srinivasa Murthy 249 Freescale Semiconductor 250 UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA 251 HYDERABAD 500082 252 INDIA 254 Email: ssmurthy.nittala@freescale.com