Network Working Group A. Kato Internet-Draft S. Kanno Intended status: Standards Track NTT Software Corporation Expires: September 9, 2009 M. Kanda Nippon Telegraph and Telephone Corporation March 8, 2009 The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and Its Use With IPsec draft-kato-ipsec-camellia-gcm-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 9, 2009. Copyright Notice Kato, et al. Expires September 9, 2009 [Page 1] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 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. Kato, et al. Expires September 9, 2009 [Page 2] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Camelllia-GCM . . . . . . . . . . . . . . . . . . . . . . . . 5 3. IKE Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Keying Material and Salt Values . . . . . . . . . . . . . 6 3.2. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . 6 3.3. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . 6 3.4. Key Length Attribute . . . . . . . . . . . . . . . . . . . 7 4. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Kato, et al. Expires September 9, 2009 [Page 3] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 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. The algorithm specification and object identifiers are described in [5]. 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]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. Kato, et al. Expires September 9, 2009 [Page 4] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 2. Camelllia-GCM Camellia-GCM comply with [2] on following points: - ESP Payload Data - Initialization Vector - Cipher text - Nonce Format - AAD Construction - Integrity Check Value - Packet Expansion Kato, et al. Expires September 9, 2009 [Page 5] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 3. 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) [4] protocol. The identifiers and attributes needed to negotiate a security association using Camellia- GCM-ESP are also defined. 3.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. 3.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 [6] with the same key size used by Camellia- GCM-ESP is RECOMMENDED. 3.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, et al. Expires September 9, 2009 [Page 6] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 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. 3.4. Key Length Attribute Because the Camellia supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [4]. The Key Length attribute MUST have a value of 128, 192, or 256. Kato, et al. Expires September 9, 2009 [Page 7] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 4. Test Vectors TBD. Kato, et al. Expires September 9, 2009 [Page 8] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 5. 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 [7], [8] For other security considerations, please refer to the security considerations of the previous use of GMC mode document described in [2]. Kato, et al. Expires September 9, 2009 [Page 9] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 6. 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, et al. Expires September 9, 2009 [Page 10] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 7. Acknowledgments Portions of this text were unabashedly borrowed from [2]. Kato, et al. Expires September 9, 2009 [Page 11] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 8. References 8.1. Normative [1] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) for Confidentiality and Authentication", April 2006, . [2] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [5] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004. [6] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, December 2005. 8.2. Informative [7] "The NESSIE project (New European Schemes for Signatures, Integrity and Encryption)", . [8] Information-technology Promotion Agency (IPA), "Cryptography Research and Evaluation Committees", . Kato, et al. Expires September 9, 2009 [Page 12] Internet-Draft The GCM Mode of Camellia in IPsec March 2009 Authors' Addresses Akihiro Kato NTT Software Corporation Phone: +81-45-212-7614 Fax: +81-45-212-7528 Email: akato@po.ntts.co.jp Satoru Kanno NTT Software Corporation Phone: +81-45-212-7577 Fax: +81-45-212-9800 Email: kanno-s@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, et al. Expires September 9, 2009 [Page 13]