idnits 2.17.1 draft-kato-ipsec-camellia-modes-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2009) is 5536 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 (ref. '1') (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational RFC: RFC 3713 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kato 3 Internet-Draft NTT Software Corporation 4 Intended status: Standards Track M. Kanda 5 Expires: August 30, 2009 Nippon Telegraph and Telephone 6 Corporation 7 S. Kanno 8 NTT Software Corporation 9 February 26, 2009 11 Modes of Operation for Camellia for Use With IPsec 12 draft-kato-ipsec-camellia-modes-10 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 30, 2009. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes the use of the Camellia block cipher 60 algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, 61 and Counter with CBC-MAC (CCM) mode, as an IKEv2 and Encapsulating 62 Security Payload (ESP) mechanism to provide confidentiality, data 63 origin authentication, and connectionless integrity. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. The Camellia Cipher Algorithm . . . . . . . . . . . . . . . . 5 70 2.1. Block Size and Padding . . . . . . . . . . . . . . . . . . 5 71 2.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. Cipher Block Chaining . . . . . . . . . . . . . . . . . . 6 74 3.2. Counter and Counter with CBC-MAC . . . . . . . . . . . . . 6 75 4. IKEv2 Conventions . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 7 77 4.2. Transform Type 1 . . . . . . . . . . . . . . . . . . . . . 8 78 4.3. Key Length Attribute . . . . . . . . . . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 12 84 8.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 This document describes the use of the Camellia block cipher 90 algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, 91 and Counter with CBC-MAC (CCM) mode, as an IKEv2 [1] and 92 Encapsulating Security Payload (ESP) [2] mechanism to provide 93 confidentiality, data origin authentication, and connectionless 94 integrity. 96 Since optimized source code is provided under several open source 97 licenses [9], Camellia is also adopted by several open source 98 projects (OpenSSL, FreeBSD, Linux, and Firefox Gran Paradiso). 100 The algorithm specification and object identifiers are described in 101 [3]. 103 The Camellia web site [10] contains a wealth of information about 104 Camellia, including detailed specification, security analysis, 105 performance figures, reference implementation, optimized 106 implementation, test vectors, and intellectual property information. 108 The remainder of this document specifies use of various modes of 109 operation for Camellia within the context of IPsec ESP. For further 110 information on how the various pieces of IPsec in general and ESP in 111 particular fit together to provide security services, please refer to 112 [11] and [2]. 114 1.1. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [4]. 120 2. The Camellia Cipher Algorithm 122 All symmetric block cipher algorithms share common characteristics 123 and variables, including mode, key size, weak keys, block size, and 124 rounds. The relevant characteristics of Camellia describes in [3]. 126 2.1. Block Size and Padding 128 Camellia uses a block size of 16 octets (128 bits). 130 Padding requirements are described: 132 a) Camellia Padding requirement is specified in [2], 133 b) Camellia-CBC Padding requirement is specified in [2], 134 c) Camellia-CCM Padding requirement is specified in [5], 135 d) ESP Padding requirement is specified in [2]. 137 2.2. Performance 139 Performance figures for Camellia are available at [10]. The NESSIE 140 project has reported on the performance of optimized implementations 141 independently [12]. 143 3. Modes 145 This document describes three modes of operation(CBC (Cipher Block 146 Chaining), CTR (Counter), CCM (Counter with CBC MAC)) for Camellia on 147 IPsec. 149 3.1. Cipher Block Chaining 151 Camellia CBC mode is defined in [6]. 153 3.2. Counter and Counter with CBC-MAC 155 Camellia in CTR and CCM modes is used in IPsec as AES in [7] and [8]. 156 In this specification, CCM is used with the Camellia [13] block 157 cipher. 159 4. IKEv2 Conventions 161 This section describes the transform ID and conventions used to 162 generate keying material for use with ENCR_CAMELLIA_CBC, 163 ENCR_CAMELLIA_CTR and ENCR_CAMELLIA_CCM using the Internet Key 164 Exchange (IKEv2) [1]. 166 4.1. Keying Material 168 The size of KEYMAT MUST be equal or longer than the associated 169 Camellia key. The keying material is used as follows: 171 Camellia-CBC with a 128-bit key 172 The KEYMAT requested for each Camellia-CBC key is 16 octets. The 173 whole octets are the 128-bit Camellia key. 175 Camellia-CBC with a 192-bit key 176 The KEYMAT requested for each Camellia-CBC key is 24 octets. The 177 whole octets are the 192-bit Camellia key. 179 Camellia-CBC with a 256-bit key 180 The KEYMAT requested for each Camellia-CBC key is 32 octets. The 181 whole octets are the 256-bit Camellia key. 183 Camellia-CTR with a 128-bit key 184 The KEYMAT requested for each Camellia-CTR key is 20 octets. The 185 first 16 octets are the 128-bit Camellia key, and the remaining 186 four octets are used as the nonce value in the counter block. 188 Camellia-CTR with a 192-bit key 189 The KEYMAT requested for each Camellia-CTR key is 28 octets. The 190 first 24 octets are the 192-bit Camellia key, and the remaining 191 four octets are used as the nonce value in the counter block. 193 Camellia-CTR with a 256-bit key 194 The KEYMAT requested for each Camellia-CTR key is 36 octets. The 195 first 32 octets are the 256-bit Camellia key, and the remaining 196 four octets are used as the nonce value in the counter block. 198 Camellia-CCM with a 128-bit key 199 The KEYMAT requested for each Camellia-CCM key is 19 octets. The 200 first 16 octets are the 128-bit Camellia key, and the remaining 201 three octets are used as the salt value in the counter block. 203 Camellia-CCM with a 192-bit key 204 The KEYMAT requested for each Camellia-CCM key is 27 octets. The 205 first 24 octets are the 192-bit Camellia key, and the remaining 206 three octets are used as the salt value in the counter block. 208 Camellia-CCM with a 256-bit key 209 The KEYMAT requested for each Camellia-CCM key is 35 octets. The 210 first 32 octets are the 256-bit Camellia key, and the remaining 211 three octets are used as the salt value in the counter block. 213 4.2. Transform Type 1 215 For IKEv2 negotiations, IANA has assigned five ESP Transform 216 Identifiers for Camellia-CBC, Camellia-CTR and Camellia-CCM: 218 for Camellia-CBC with explicit IV; 219 for Camellia-CTR with explicit IV; 220 for Camellia-CCM with an 8-octet ICV; 221 for Camellia-CCM with a 12-octet ICV; and 222 for Camellia-CCM with a 16-octet ICV. 224 4.3. Key Length Attribute 226 Since Camellia supports three key lengths, the Key Length attribute 227 MUST be specified in the IKE exchange [1]. The Key Length attribute 228 MUST have a value of 128, 192, or 256 bits. 230 5. Security Considerations 232 About security considerations of CTR and CCM mode, this document 233 refers to Section 9. of [7] and Section 7. of [8]. 235 No security problem has been found for Camellia [14], [12]. 237 6. IANA Considerations 239 IANA has assigned IKEv2 parameters for use with Camellia-CTR, and 240 Camellia-CCM for Transform Type 1 (Encryption Algorithm): 242 for ENCR_CAMELLIA_CBC; 243 for ENCR_CAMELLIA_CTR; 244 for ENCR_CAMELLIA_CCM with an 8-octet ICV; 245 for ENCR_CAMELLIA_CCM with a 12-octet ICV; and 246 for ENCR_CAMELLIA_CCM with a 16-octet ICV. 248 7. Acknowledgments 250 We thank Tim Polk and Tero Kivinen for their initial review of this 251 document. Thanks to Derek Atkins, Rui Hodai for their comments and 252 suggestions. Special thanks to Alfred Hoenes for several very 253 detailed reviews and suggestions. 255 8. References 257 8.1. Normative 259 [1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 260 RFC 4306, December 2005. 262 [2] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 263 December 2005. 265 [3] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the 266 Camellia Encryption Algorithm", RFC 3713, April 2004. 268 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 269 Levels", BCP 14, RFC 2119, March 1997. 271 [5] Dworkin, M., "Recommendation for Block Cipher Modes of 272 Operation: the CCM Mode for Authentication and 273 Confidentiality", NIST Special Publication 800-38C, July 2007, 274 . 277 [6] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher 278 Algorithm and Its Use With IPsec", RFC 4312, December 2005. 280 [7] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode 281 with IPsec Encapsulating Security Payload (ESP)", RFC 4309, 282 December 2005. 284 [8] Housley, R., "Using Advanced Encryption Standard (AES) Counter 285 Mode With IPsec Encapsulating Security Payload (ESP)", 286 RFC 3686, January 2004. 288 8.2. Informative 290 [9] "Camellia open source software", 291 . 293 [10] "Camellia web site", . 295 [11] Kent, S. and K. Seo, "Security Architecture for the Internet 296 Protocol", RFC 4301, December 2005. 298 [12] "The NESSIE project (New European Schemes for Signatures, 299 Integrity and Encryption)", 300 . 302 [13] Kato, A., Kanda, M., and S. Kanno, "Camellia Counter mode and 303 Camellia Counter with CBC Mac mode algorithms", 304 draft-kato-camellia-ctrccm-05 (work in progress), 305 February 2009. 307 [14] Information-technology Promotion Agency (IPA), "Cryptography 308 Research and Evaluation Committees", 309 . 311 Authors' Addresses 313 Akihiro Kato 314 NTT Software Corporation 316 Phone: +81-45-212-7577 317 Fax: +81-45-212-9800 318 Email: akato@po.ntts.co.jp 320 Masayuki Kanda 321 Nippon Telegraph and Telephone Corporation 323 Phone: +81-422-59-3456 324 Fax: +81-422-59-4015 325 Email: kanda.masayuki@lab.ntt.co.jp 327 Satoru Kanno 328 NTT Software Corporation 330 Phone: +81-45-212-7577 331 Fax: +81-45-212-9800 332 Email: kanno-s@po.ntts.co.jp