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
<TBD1> for Camellia-GCM with an 8 octet ICV;
<TBD2> for Camellia-GCM with a 12 octet ICV; and
<TBD3> 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:
<TBD1> for Camellia-GCM with an 8 octet ICV;
<TBD2> for Camellia-GCM with a 12 octet ICV; and
<TBD3> 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, <http://csrc.nist.gov/
publications/drafts/Draft-NIST_SP800-38D_Public_Comment.pdf>.
[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,
<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[16] "The NESSIE project (New European Schemes for Signatures,
Integrity and Encryption)",
<http://www.cosic.esat.kuleuven.ac.be/nessie/>.
[17] Information-technology Promotion Agency (IPA), "Cryptography
Research and Evaluation Committees",
<http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html>.
[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] <http://info.isl.ntt.co.jp/crypt/eng/camellia/source.html>
[20] <http://info.isl.ntt.co.jp/camellia/>
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]