Network Working Group A. Kato Internet-Draft NTT Software Corporation Intended status: Standards Track M. Kanda Expires: August 29, 2007 Nippon Telegraph and Telephone Corporation February 25, 2007 The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and Its Use With IPsec draft-kato-ipsec-camellia-gcm-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Kato & Kanda Expires August 29, 2007 [Page 1] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 Abstract This document describes the use of the Camellia block ciper algorithm in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Camelllia-GCM . . . . . . . . . . . . . . . . . . . . . . . . 5 3. ESP Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Initialization Vector (IV) . . . . . . . . . . . . . . . . 6 3.2. Ciphertext . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Nonce Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. AAD Construction . . . . . . . . . . . . . . . . . . . . . . . 8 6. Integrity Check Value (ICV) . . . . . . . . . . . . . . . . . 9 7. Packet Expansion . . . . . . . . . . . . . . . . . . . . . . . 10 8. IKE Conventions . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Keying Material and Salt Values . . . . . . . . . . . . . 11 8.2. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . 11 8.3. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . 11 8.4. Key Length Attribute . . . . . . . . . . . . . . . . . . . 12 9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 17 13.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Kato & Kanda Expires August 29, 2007 [Page 2] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 1. Introduction This document describes the use of the Camellia block cipher algorithm in GCM Mode (Camellia-GCM), as an IPsec ESP mechanism to provide confidentiality, and data origin authentication. We refer to this method as Camellia-GCM-ESP. Camellia is a symmetric cipher with a Feistel structure. Camellia was developed jointly by NTT and Mitsubishi Electric Corporation in 2000. It was designed to withstand all known cryptanalytic attacks, and it has been scrutinized by worldwide cryptographic experts. Camellia is suitable for implementation in software and hardware, offering encryption speed in software and hardware implementations that is comparable to Advanced Encryption Standard (AES) [15]. Camellia supports 128-bit block size and 128-, 192-, and 256-bit key lengths, i.e., the same interface specifications as the AES. Therefore it is easy to implement Camellia-GCM by replacing AES block of AES-GCM [1] to Camellia. Camellia is adopted as IETF and several international standardization organizations. Camellia is already adopted as IPSec [8], TLS [12], S/MIME [10] and XML [11]. Camellia is adopted for the one of three ISO/IEC international standard cipher [18] as 128bit block cipher(Camellia AES and SEED). Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project [16] and was included in the list of cryptographic techniques for Japanese e-Government systems that was selected by the Japan CRYPTREC (Cryptography Research and Evaluation Committees) [17]. Since optimized source code is provided by several open source lisences [19], Camellia is also adopted by several open source projects. Camellia is already adopted by Openssl. Additional API for Network Security Services (NSS) and IPsec stack of Linux and Free BSD are prepared or working progress for release. The algorithm specification and object identifiers are described in [5]. The Camellia homepage [20] contains a wealth of information about Camellia, including detailed specification, security analysis, performance figures, reference implementation, optimized implementetion, test vectors, and intellectual property information. GCM mode provides Counter mode (CTR) with data origin authentication. This document does not cover implementation details of GCM. Those details can be found in [1]. Kato & Kanda Expires August 29, 2007 [Page 3] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 1.1. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in [2]. Kato & Kanda Expires August 29, 2007 [Page 4] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 2. Camelllia-GCM GCM is a block cipher mode of operation providing both confidentiality and data origin authentication. The GCM authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD). It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag. In the following, we describe how the IV, plaintext, and AAD are formed from the ESP fields, and how the ESP packet is formed from the ciphertext and authentication tag. ESP also defines an IV. For clarity, we refer to the Camellia-GCM IV as a nonce in the context of Camellia-GCM-ESP. The same nonce and key combination MUST NOT be used more than once. Because reusing an nonce/key combination destroys the security guarantees of Camellia-GCM mode, it can be difficult to use this mode securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system, such as the Internet Key Exchange (IKE) [9], to ensure that this requirement is met. Kato & Kanda Expires August 29, 2007 [Page 5] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 3. ESP Payload Data The ESP Payload Data is comprised of an eight-octet initialization vector (IV), followed by the ciphertext. The payload field, as defined in [7], is structured as shown in Figure 1, along with the ICV associated with the payload. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Ciphertext (variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ESP Payload Encrypted with Camellia-GCM. 3.1. Initialization Vector (IV) The Camellia-GCM-ESP IV field MUST be eight octets. For a given key, the IV MUST NOT repeat. The most natural way to implement this is with a counter, but anything that guarantees uniqueness can be used, such as a linear feedback shift register (LFSR). Note that the encrypter can use any IV generation method that meets the uniqueness requirement, without coordinating with the decrypter. 3.2. Ciphertext The plaintext input to Camellia-GCM is formed by concatenating the plaintext data described by the Next Header field with the Padding, the Pad Length, and the Next Header field. The Ciphertext field consists of the ciphertext output from the Camellia-GCM algorithm. The length of the ciphertext is identical to that of the plaintext. Implementations that do not seek to hide the length of the plaintext SHOULD use the minimum amount of padding required, which will be less than four octets. Kato & Kanda Expires August 29, 2007 [Page 6] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 4. Nonce Format The nonce passed to the Camellia-GCM encryption algorithm has the following layout: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Salt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nonce Format The components of the nonce are as follows: salt The salt field is a four-octet value that is assigned at the beginning of the security association, and then remains constant for the life of the security association. The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret. We describe how to set the salt for a Security Association established via the Internet Key Exchange in Section Section 8.1. Initialization Vector The IV field is described in Section Section 3.1 Kato & Kanda Expires August 29, 2007 [Page 7] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 5. AAD Construction The authentication of data integrity and data origin for the SPI and (Extended) Sequence Number fields is provided without encryption. This is done by including those fields in the Camellia-GCM Additional Authenticated Data (AAD) field. Two formats of the AAD are defined: one for 32-bit sequence numbers, and one for 64-bit extended sequence numbers. The format with 32-bit sequence numbers is shown in Figure 3 , and the format with 64-bit extended sequence numbers is shown in Figure 4 . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: AAD Format with 32-bit Sequence Number 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64-bit Extended Sequence Number | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: AAD Format with 64-bit Extended Sequence Number Kato & Kanda Expires August 29, 2007 [Page 8] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 6. Integrity Check Value (ICV) The ICV consists solely of the Camellia-GCM Authentication Tag. Implementations MUST support a full-length 16-octet ICV, and MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. Although ESP does not require that an ICV be present, Camellia-GCM- ESP intentionally does not allow a zero-length ICV. This is because GCM provides no integrity protection whatsoever when used with a zero-length Authentication Tag. Kato & Kanda Expires August 29, 2007 [Page 9] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 7. Packet Expansion The IV adds an additional eight octets to the packet, and the ICV adds an additional 8, 12, or 16 octets. These are the only sources of packet expansion, other than the 10-13 octets taken up by the ESP SPI, Sequence Number, Padding, Pad Length, and Next Header fields (if the minimal amount of padding is used). Kato & Kanda Expires August 29, 2007 [Page 10] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 8. IKE Conventions This section describes the conventions used to generate keying material and salt values, for use with Camellia-GCM-ESP, using the Internet Key Exchange (IKE) [9] protocol. The identifiers and attributes needed to negotiate a security association using Camellia- GCM-ESP are also defined. 8.1. Keying Material and Salt Values IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, called KEYMAT. Keying material is extracted from the output string without regard to boundaries. The size of the KEYMAT for the Camellia-GCM-ESP MUST be four octets longer than is needed for the associated Camellia key. The keying material is used as follows: Camellia-GCM-ESP with a 128 bit key The KEYMAT requested for each Camellia-GCM key is 20 octets. The first 16 octets are the 128-bit Camellia key, and the remaining four octets are used as the salt value in the nonce. Camellia-GCM-ESP with a 192 bit key The KEYMAT requested for each Camellia-GCM key is 28 octets. The first 24 octets are the 192-bit Camellia key, and the remaining four octets are used as the salt value in the nonce. Camellia-GCM-ESP with a 256 bit key The KEYMAT requested for each Camellia GCM key is 36 octets. The first 32 octets are the 256-bit Camellia key, and the remaining four octets are used as the salt value in the nonce. 8.2. Phase 1 Identifier This document does not specify the conventions for using Camellia-GCM for IKE Phase 1 negotiations. For Camellia-GCM to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned. Implementations SHOULD use an IKE Phase 1 cipher that is at least as strong as Camellia-GCM. The use of Camellia CBC [8] with the same key size used by Camellia- GCM-ESP is RECOMMENDED. 8.3. Phase 2 Identifier For IKE Phase 2 negotiations, IANA has assigned three ESP Transform Identifiers for Camellia-GCM with an eight-byte explicit IV: Kato & Kanda Expires August 29, 2007 [Page 11] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 for Camellia-GCM with an 8 octet ICV; for Camellia-GCM with a 12 octet ICV; and for Camellia-GCM with a 16 octet ICV. 8.4. Key Length Attribute Because the Camellia supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [3]. The Key Length attribute MUST have a value of 128, 192, or 256. Kato & Kanda Expires August 29, 2007 [Page 12] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 9. Test Vectors TBD. Kato & Kanda Expires August 29, 2007 [Page 13] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 10. Security Considerations At the time of writing this document there are no known weak keys for Camellia. And no security problem has been found on Camellia [16], [17] For other security considerations, please refer to the security considerations of the previous use of GMC mode document described in [6]. Kato & Kanda Expires August 29, 2007 [Page 14] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 11. IANA Considerations IANA has assigned three ESP Transform Identifiers for Camellia-GCM with an eight-byte explicit IV: for Camellia-GCM with an 8 octet ICV; for Camellia-GCM with a 12 octet ICV; and for Camellia-GCM with a 16 octet ICV. Kato & Kanda Expires August 29, 2007 [Page 15] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 12. Acknowledgments Portions of this text were unabashedly borrowed from [6]. Kato & Kanda Expires August 29, 2007 [Page 16] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 13. References 13.1. Normative [1] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) for Confidentiality and Authentication", April 2006, . [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [4] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [5] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004. [6] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [8] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, December 2005. 13.2. Informative [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [10] Moriai, S. and A. Kato, "Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3657, January 2004. [11] Eastlake, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005. [12] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia Cipher Suites to Transport Layer Security (TLS)", RFC 4132, July 2005. [13] Kent, S. and K. Seo, "Security Architecture for the Internet Kato & Kanda Expires August 29, 2007 [Page 17] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 Protocol", RFC 4301, December 2005. [14] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [15] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, . [16] "The NESSIE project (New European Schemes for Signatures, Integrity and Encryption)", . [17] Information-technology Promotion Agency (IPA), "Cryptography Research and Evaluation Committees", . [18] International Organization for Standardization, "Information technology - Security techniques - Encryption algorithms - Part 3: Block ciphers", ISO/IEC 18033-3, July 2005. Kato & Kanda Expires August 29, 2007 [Page 18] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 URIs [19] [20] Kato & Kanda Expires August 29, 2007 [Page 19] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 Authors' Addresses Akihiro Kato NTT Software Corporation Phone: +81-45-212-7614 Fax: +81-45-212-7528 Email: akato@po.ntts.co.jp Masayuki Kanda Nippon Telegraph and Telephone Corporation Phone: +81-46-859-2437 Fax: +81-46-859-3365 Email: kanda@isl.ntt.co.jp Kato & Kanda Expires August 29, 2007 [Page 20] Internet-Draft The GCM Mode of Camellia in IPsec February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kato & Kanda Expires August 29, 2007 [Page 21]