< draft-kato-ipsec-camellia-gcm-02.txt   draft-kato-ipsec-camellia-gcm-03.txt >
Network Working Group A. Kato Network Working Group A. Kato
Internet-Draft S. Kanno Internet-Draft S. Kanno
Intended status: Standards Track NTT Software Corporation Intended status: Standards Track NTT Software Corporation
Expires: March 13, 2010 M. Kanda Expires: July 8, 2010 M. Kanda
NTT NTT
September 9, 2009 January 4, 2010
The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and The Use of Galois/Counter Mode (GCM) for the Camellia Block Cipher With
Its Use With IPsec IPsec ESP
draft-kato-ipsec-camellia-gcm-02 draft-kato-ipsec-camellia-gcm-03
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 13, 2010. This Internet-Draft will expire on July 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document describes the use of the Camellia block ciper algorithm This document may contain material from IETF Documents or IETF
in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Contributions published or made publicly available before November
Payload (ESP) mechanism to provide confidentiality and data origin 10, 2008. The person(s) controlling the copyright in some of this
authentication. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Camelllia-GCM . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Camelllia-GCM . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IKE Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 3. IKE Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Keying Material and Salt Values . . . . . . . . . . . . . 6 3.1. Keying Material and Salt Values . . . . . . . . . . . . . 6
3.2. Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . 6 3.2. Key Length Attribute . . . . . . . . . . . . . . . . . . . 6
3.3. Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . 6 4. Test Vector . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Key Length Attribute . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document describes the use of the Camellia block cipher This document describes the use of the Camellia block cipher
algorithm in GCM Mode (Camellia-GCM) , as an IPsec ESP mechanism to algorithm in the GCM (Galois/Counter Mode) [2], is called Camellia-
provide confidentiality, and data origin authentication. We refer to GCM, as an IPsec ESP mechanism to provide confidentiality and data
this method as Camellia-GCM-ESP. origin authentication. We refer to this method as Camellia-GCM-ESP.
The algorithm specification and object identifiers are described in The Camellia algorithm and its properties are described in [5].
[5].
GCM mode provides Counter mode (CTR) with data origin authentication. GCM mode provides Counter mode (CTR) encryption with data origin
This document does not cover implementation details of GCM. Those authentication. This document does not cover implementation details
details can be found in [1]. of GCM. Those details can be found in [2].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [3]. document are to be interpreted as described in [1].
2. Camelllia-GCM 2. Camelllia-GCM
Camellia-GCM comply with [2] on following points: Camellia-GCM complies with [3] in the following points:
- ESP Payload Data - ESP Payload Data
- Initialization Vector - Initialization Vector
- Cipher text - Cipher text
- Nonce Format - Nonce Format
- AAD Construction - AAD Construction
- Integrity Check Value - Integrity Check Value
- Packet Expansion - Packet Expansion
3. IKE Conventions 3. IKE Conventions
This section describes the conventions used to generate keying This section describes the conventions used to generate keying
material and salt values, for use with Camellia-GCM-ESP, using the material and salt values for use with Camellia-GCM-ESP, using the
Internet Key Exchange (IKE) [4] protocol. The identifiers and Internet Key Exchange version 2 (IKEv2) [4] protocol. The
attributes needed to negotiate a security association using Camellia- identifiers and attributes needed to negotiate a security association
GCM-ESP are also defined. using Camellia-GCM-ESP are also defined.
This applies to the use of any authenticated encryption algorithm
with the IKEv2 Encrypted Payload and is unique to that usage.
IKEv2 [4] specifies that both an encryption algorithm and an
integrity checking algorithm are required for an IKE SA (Security
Association).
3.1. Keying Material and Salt Values 3.1. Keying Material and Salt Values
IKE makes use of a pseudo-random function (PRF) to derive keying IKE makes use of a pseudo-random function (PRF) to derive keying
material. The PRF is used iteratively to derive keying material of material. The PRF is used iteratively to derive keying material of
arbitrary size, called KEYMAT. Keying material is extracted from the arbitrary size, called KEYMAT. Keying material is extracted from the
output string without regard to boundaries. output string without regard to boundaries.
The size of the KEYMAT for the Camellia-GCM-ESP MUST be four octets 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 longer than is needed for the associated Camellia key. The keying
skipping to change at page 6, line 39 skipping to change at page 6, line 46
Camellia-GCM-ESP with a 192 bit key Camellia-GCM-ESP with a 192 bit key
The KEYMAT requested for each Camellia-GCM key is 28 octets. The The KEYMAT requested for each Camellia-GCM key is 28 octets. The
first 24 octets are the 192-bit Camellia key, and the remaining first 24 octets are the 192-bit Camellia key, and the remaining
four octets are used as the salt value in the nonce. four octets are used as the salt value in the nonce.
Camellia-GCM-ESP with a 256 bit key Camellia-GCM-ESP with a 256 bit key
The KEYMAT requested for each Camellia GCM key is 36 octets. The The KEYMAT requested for each Camellia GCM key is 36 octets. The
first 32 octets are the 256-bit Camellia key, and the remaining first 32 octets are the 256-bit Camellia key, and the remaining
four octets are used as the salt value in the nonce. four octets are used as the salt value in the nonce.
3.2. Phase 1 Identifier 3.2. Key Length Attribute
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:
<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.
3.4. Key Length Attribute
Because the Camellia supports three key lengths, the Key Length Because the Camellia supports three key lengths, the Key Length
attribute MUST be specified in the IKE Phase 2 exchange [4]. The Key attribute MUST be specified in the IKEv2 [4]. The Key Length
Length attribute MUST have a value of 128, 192, or 256. attribute MUST have a value of 128, 192, or 256.
4. Test Vectors 4. Test Vector
This section contains 18 test vectors(TV), which can be used to This section contains 18 test vectors, which can be used to confirm
confirm that an implementation has correctly implemented Camellia- that an implementation has correctly implemented Camellia-GCM.
GCM.
------ Spec Test Case 1 (Camellia-128) ------ ------ Spec Test Case 1 (Camellia-128) ------
KEY : 00000000000000000000000000000000 KEY : 00000000000000000000000000000000
IV : 000000000000000000000000 IV : 000000000000000000000000
T : f5574acc3148dfcb9015200631024df9 T : f5574acc3148dfcb9015200631024df9
------ Spec Test Case 2 (Camellia-128) ------ ------ Spec Test Case 2 (Camellia-128) ------
KEY : 00000000000000000000000000000000 KEY : 00000000000000000000000000000000
IV : 000000000000000000000000 IV : 000000000000000000000000
P : 00000000000000000000000000000000 P : 00000000000000000000000000000000
skipping to change at page 12, line 7 skipping to change at page 11, line 7
c3c0c95156809539fcf0e2429a6b525416aedbf5a0de6a57a637b39b c3c0c95156809539fcf0e2429a6b525416aedbf5a0de6a57a637b39b
AD : feedfacedeadbeeffeedfacedeadbeefabaddad2 AD : feedfacedeadbeeffeedfacedeadbeefabaddad2
P : d9313225f88406e5a55909c5aff5269a86a7a9531534f7da2e4c303d8a318a72 P : d9313225f88406e5a55909c5aff5269a86a7a9531534f7da2e4c303d8a318a72
1c3c0c95956809532fcf0e2449a6b525b16aedf5aa0de657ba637b39 1c3c0c95956809532fcf0e2449a6b525b16aedf5aa0de657ba637b39
C : e0cddd7564d09c4dc522dd65949262bbf9dcdb07421cf67f3032becb7253c284 C : e0cddd7564d09c4dc522dd65949262bbf9dcdb07421cf67f3032becb7253c284
a16e5bf0f556a308043f53fab9eebb526be7f7ad33d697ac77c67862 a16e5bf0f556a308043f53fab9eebb526be7f7ad33d697ac77c67862
T : 5791883f822013f8bd136fc36fb9946b T : 5791883f822013f8bd136fc36fb9946b
5. Security Considerations 5. Security Considerations
At the time of writing this document there are no known weak keys for At the time of writing of this document there are no known weak keys
Camellia. And no security problem has been found on Camellia [7], for Camellia and no security problems have been found with Camellia
[8] (see [7], [8]).
For other security considerations, please refer to the security For other security considerations, please refer to the security
considerations of the previous use of GMC mode document described in considerations of the previous documents describing the use of GCM
[2]. mode with IPsec [3].
6. IANA Considerations 6. IANA Considerations
IANA has assigned three ESP Transform Identifiers for Camellia-GCM IANA has assigned three Transform Type 1 (Encryption Algorithm)
with an eight-byte explicit IV: Identifiers for Camellia-GCM with an eight-byte explicit IV in the
"IKEv2 Parameters" registry:
<TBD1> for Camellia-GCM with an 8 octet ICV; Number Name Reference
<TBD2> for Camellia-GCM with a 12 octet ICV; and -------- --------------------------------------- -----------
<TBD3> for Camellia-GCM with a 16 octet ICV. <TBD1> Camellia-GCM with an 8 octet ICV [RFCxxxx]
<TBD2> Camellia-GCM with a 12 octet ICV [RFCxxxx]
<TBD3> Camellia-GCM with a 16 octet ICV [RFCxxxx]
[[ IANA and RFC Editor: please substitute the RFC number assigned
to this document for 'xxxx' above. ]]
7. Acknowledgments 7. Acknowledgments
Portions of this text were unabashedly borrowed from [2]. Portions of this text were unabashedly borrowed from [3].
8. References 8. References
8.1. Normative 8.1. Normative
[1] Dworkin, M., "Recommendation for Block Cipher Modes of [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) for Confidentiality and Operation: Galois/Counter Mode (GCM) for Confidentiality and
Authentication", April 2006, <http://csrc.nist.gov/publications/ Authentication", November 2007, <http://csrc.nist.gov/
drafts/Draft-NIST_SP800-38D_Public_Comment.pdf>. publications/nistpubs/800-38D/SP-800-38D.pdf>.
[2] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) [3] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM)
in IPsec Encapsulating Security Payload (ESP)", RFC 4106, in IPsec Encapsulating Security Payload (ESP)", RFC 4106,
June 2005. 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, [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005. December 2005.
[5] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the [5] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the
Camellia Encryption Algorithm", RFC 3713, April 2004. Camellia Encryption Algorithm", RFC 3713, April 2004.
[6] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher [6] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher
Algorithm and Its Use With IPsec", RFC 4312, December 2005. Algorithm and Its Use With IPsec", RFC 4312, December 2005.
8.2. Informative 8.2. Informative
skipping to change at page 16, line 10 skipping to change at page 15, line 10
[8] Information-technology Promotion Agency (IPA), "Cryptography [8] Information-technology Promotion Agency (IPA), "Cryptography
Research and Evaluation Committees", Research and Evaluation Committees",
<http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html>. <http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html>.
Authors' Addresses Authors' Addresses
Akihiro Kato Akihiro Kato
NTT Software Corporation NTT Software Corporation
Phone: +81-45-212-7614 Phone: +81-45-212-9803
Fax: +81-45-212-7528 Fax: +81-45-212-9800
Email: kato.akihiro@po.ntts.co.jp Email: kato.akihiro@po.ntts.co.jp
Satoru Kanno Satoru Kanno
NTT Software Corporation NTT Software Corporation
Phone: +81-45-212-7577 Phone: +81-45-212-9803
Fax: +81-45-212-9800 Fax: +81-45-212-9800
Email: kanno.satoru@po.ntts.co.jp Email: kanno.satoru@po.ntts.co.jp
Masayuki Kanda Masayuki Kanda
NTT NTT
Phone: +81-46-859-2437 Phone: +81-422-59-3456
Fax: +81-46-859-3365 Fax: +81-422-59-4015
Email: kanda@isl.ntt.co.jp Email: kanda.masayuki@lab.ntt.co.jp
 End of changes. 31 change blocks. 
100 lines changed or deleted 95 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/