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
T. Iwata
Nagoya University
February 25, 2007
The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use
with IPsec
draft-kato-ipsec-camellia-cmac96and128-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, et al. Expires August 29, 2007 [Page 1]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
Abstract
This memo specifies two new alogorithms. One is the usage of Cipher-
based Message Authentication Code (CMAC) with Camellia block cipher
on the authentication mechanism of the IPsec Encapsulating Security
Payload and Authentication Header protocols. This algoritm is called
Camellia-CMAC-96. Latter is a pseudo-random function based on CMAC
with Camellia block cipher for Internet Key Exchange. This algoritm
is called Camellia-CMAC-PRF-128.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Camellia-CMAC and Camellia128-CMAC . . . . . . . . . . . . . . 7
4. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . . . 8
5. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . . . 9
6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Kato, et al. Expires August 29, 2007 [Page 2]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
1. Introduction
This memo specifies two new alogorithms. One is the usage of CMAC
based on Camellia block cipher on the authentication mechanism of the
IPsec Encapsulating Security Payload (ESP) [4] and Authentication
Header protocols (AH) [3]. This algorithm is called
Camellia-CMAC-96. Latter is a Pseudo-Random Function (PRF) based on
CMAC with Camellia block cipher for Internet Key Exchange (IKE) [5].
This algoritm is called Camellia-CMAC-PRF-128.
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) [18].
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-CMAC by replacing AES
block of AES-CMAC to Camellia.
Camellia is adopted as IETF and several international standardization
organizations. Camellia is already adopted as IPSec [15], TLS [13],
S/MIME [10] and XML [11]. Camellia is adopted for the one of three
ISO/IEC international standard cipher [21] as 128-bit 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 [19] 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) [20].
Since optimized source code is provided by several open source
lisences [22], 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
[8].
The Camellia homepage [23] contains a wealth of information about
Camellia, including detailed specification, security analysis,
performance figures, reference implementation, optimized
implementetion, test vectors, and intellectual property information.
Kato, et al. Expires August 29, 2007 [Page 3]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
This document specifies the usage of CMAC with Camellia Block cipher
on the authentication mechanism of the IPsec Encapsulating Security
Payload [4] and Authentication Header [3] protocols. This new
algorithm is named Camellia-CMAC-96.
NIST CMAC specification document [1] describes a method to use the
Advanced Encryption Standard (AES) as a Message Authentication Code
(MAC) that has a 128-bit output length. The 128-bit output is useful
as a long-lived pseudo-random function (PRF). This document also
specifies a PRF based on CMAC with Camellia block cipher that
supports fixed and variable key sizes for IKEv2 [5] Key Derivation
Function (KDF) and authentication. This new alogrithm is named
Camellia-CMAC-PRF-128. For further information on IKE, AH and ESP,
refer to [5], [3], [4] and [7].
This document does not cover implementation details of CMAC. Those
details can be found in [1].
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, et al. Expires August 29, 2007 [Page 4]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
2. Definitions
CBC
Cipher Block Chaining mode of operation for message
authentication code.
MAC
Message Authentication Code. A bit string of a fixed
length, computed by the MAC generation algorithm, that is
used to establish the authority and, hence, the integrity
of a message.
CMAC
Cipher-based MAC based on a symmetric key block cipher.
Key (K)
128-bit (16-octet) key for Camellia. Denoted by K.
Variable-length Key (VK)
Variable-length key for Camellia-CMAC-PRF-128, denoted by
VK.
Message (M)
Message to be authenticated. Denoted by M.
Length (len)
The length of message M in octets. Denoted by len. The
minimum value is 0. The maximum value is not specified in
this document.
VKlen
The length of VK in octets.
truncate(T,l)
Truncate T (MAC) in most-significant-bit-first (MSB-first)
order to a length of l octets.
T
The output of Camellia128-CMAC.
Truncated T
The truncated output of Camellia128-CMAC in MSB-first
order.
Camellia128-CMAC
The CMAC generation function based on Camellia block cipher
with 128-bit key.
Kato, et al. Expires August 29, 2007 [Page 5]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
Camellia-CMAC-96
IPsec AH and ESP MAC generation function based on
Camellia128-CMAC, which truncates the 96 most significant
bits of the 128-bit output.
Camellia-CMAC-PRF-128
IPsec AH and ESP PRF based on Camellia128-CMAC, which
removes 128-bit key length restriction.
Kato, et al. Expires August 29, 2007 [Page 6]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
3. Camellia-CMAC and Camellia128-CMAC
The National Institute of Standards and Technology (NIST) specified
the Cipher-based Message Authentication Code (CMAC) [1]. CMAC is a
keyed hash function that is based on a symmetric key block cipher,
such as the Advanced Encryption Standard [18]. The CMAC algorithm
provides a framework for inserting various block cipher algorithm.
Camellia-CMAC uses the Camellia block cipher [8] as a building block
in CMAC [1]. To generate a MAC, Camellia-CMAC takes a secret key, a
message of variable length, and the length of the message in octets
as inputs and returns a fixed-bit string.
Camellia-CMAC provides stronger assurance of data integrity than a
checksum or an error detecting code, as well as AES-CMAC. The output
of Camellia-CMAC can validate the input message. Validating the
message provides assurance of the integrity and authenticity over the
message from the source.
Hereafter, we define Camellia128-CMAC as special case of Camellia-
CMAC that allows only a 128-bit secret key. Therefore, Camellia128-
CMAC takes a secret key, a message of variable length, and the length
of the message in octets as inputs. Camellia128-CMAC is the
identical algorithm which is replacing AES-128 in Figure 2.3 of [6]
to Camellia with 128-bit key.
Kato, et al. Expires August 29, 2007 [Page 7]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
4. Camellia-CMAC-96
For IPsec message authentication on AH and ESP, Camellia-CMAC-96 MAY
be used. Camellia-CMAC-96 is a Camellia128-CMAC, defined in
Section 3, with 96-bit truncated output in MSB-first order. The
output is a 96-bit MAC that will meet the default authenticator
length as specified in [3]. The result of truncation is taken in
MSB-first order.
Figure 1 describes Camellia-CMAC-96 algorithm:
In step 1, Camellia128-CMAC is applied to the message M in length len
with key K.
In step 2, the output block T is truncated to 12 octets in MSB-first
order, and Truncated T (TT) is returned.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Algorithm Camellia-CMAC-96 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Input : K (128-bit Key) +
+ : M (message to be authenticated) +
+ : len (length of message in octets) +
+ Output : Truncated T (truncated output to length 12 octets) +
+ +
+-------------------------------------------------------------------+
+ +
+ Step 1. T := Camellia128-CMAC (K,M,len); +
+ Step 2. TT := truncate (T, 12); +
+ return TT; +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1: Algorithm Camellia-CMAC-96
Kato, et al. Expires August 29, 2007 [Page 8]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
5. Camellia-CMAC-PRF-128
The Camellia-CMAC-PRF-128 algorithm is identical to Camellia128-CMAC,
defined in Section 3, except that the 128-bit key length restriction
is removed.
IKEv2 [5] uses PRFs for multiple purposes, most notably for
generating keying material and authentication of the IKE_SA. The
IKEv2 specification differentiates between PRFs with fixed key sizes
and those with variable key sizes.
When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2,
Camellia-CMAC-PRF-128 is considered to take fixed size (16 octets)
keys for generating keying material but it takes variable key sizes
for authentication.
That is, when generating keying material, "half the bits must come
from Ni and half from Nr, taking the first bits of each" as described
in IKEv2, section 2.14; but for authenticating with shared secrets
(IKEv2, section 2.16), the shared secret does not have to be 16
octets and the length may vary.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Camellia-CMAC-PRF-128 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Input : VK (Variable-length key) +
+ : M (Message, i.e., the input data of the PRF) +
+ : VKlen (length of VK in octets) +
+ : len (length of M in octets) +
+ Output : PRV (128-bit Pseudo-Random Variable) +
+ +
+-------------------------------------------------------------------+
+ Variable: K (128-bit key for Camellia128-CMAC) +
+ +
+ Step 1. If VKlen is equal to 16 +
+ Step 1a. then +
+ K := VK; +
+ Step 1b. else +
+ K := Camellia128-CMAC(0^128, VK, VKlen); +
+ Step 2. PRV := Camellia128-CMAC(K, M, len); +
+ return PRV; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 2: Algorithm Camellia-CMAC-PRF-128
In step 1, the 128-bit key, K, for Camellia128-CMAC is derived as
Kato, et al. Expires August 29, 2007 [Page 9]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
follows:
o If the key, VK, is exactly 128 bits, then we use it as-is.
o If it is longer or shorter than 128 bits, then we derive the key,
K, by applying the Camellia128-CMAC algorithm using the 128-bit
all-zero string as the key and VK as the input message. This step
is described in step 1b.
In step 2, we apply the Camellia128-CMAC algorithm using K as the key
and M as the input message. The output of this algorithm is
returned.
Kato, et al. Expires August 29, 2007 [Page 10]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
6. Test Vectors
TBD.
Kato, et al. Expires August 29, 2007 [Page 11]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
7. Security Considerations
The security provided by Camellia-CMAC-96 and Camellia-CMAC-PRF-128
is built on the strong cryptographic algorithm Camellia and CMAC. At
the time of this writing, there are no known practical cryptographic
attacks against Camellia and CMAC.
However, as is true with any cryptographic algorithm, part of its
strength lies in the secret key, K and VK, and the correctness of the
implementation in all of the participating systems. If the secret
key is compromised or inappropriately shared, it guarantees neither
authentication nor integrity of message at all. The secret key shall
be independently and randomly generated in a way that meets the
pseudo randomness requirement of RFC 4086 [12] and should be kept
safe.
For Camellia-CMAC-PRF-128, if the variable-length secret key, VK, is
longer than 128 bits and it is shortened to meet the 128-bit key
size, then some entropy might be lost. However, as long as VK is
longer than 128 bits, then the new key, K, preserves sufficient
entropy, i.e., the entropy of K is about 128 bits.
Therefore, we recommend the use of VK that is longer than or equal to
128 bits and periodically refreshed, and we discourage the use of VK
that is shorter than or equal to 64 bits, because of the small
entropy.
Kato, et al. Expires August 29, 2007 [Page 12]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
8. IANA Considerations
The IANA has allocated value <TBD1> for IKEv2 Transform Type 3
(Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has
allocated a value of <TBD2> for IKEv2 Transform Type 2 (Pseudo-Random
Function) to the PRF_CAMELLIA128_CMAC algorithm.
Kato, et al. Expires August 29, 2007 [Page 13]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
9. Acknowledgements
Portions of this text were borrowed from [16] and [17].
Kato, et al. Expires August 29, 2007 [Page 14]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
10. References
10.1. Normative
[1] National Institute of Standards and Technology, "Recommendation
for Block Cipher Modes of Operation:The CMAC Mode for
Autentication", Special Publication 800-38B, May 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[6] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC
Algorithm", RFC 4493, June 2006.
[7] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
[8] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the
Camellia Encryption Algorithm", RFC 3713, April 2004.
10.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] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[13] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia
Cipher Suites to Transport Layer Security (TLS)", RFC 4132,
July 2005.
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Kato, et al. Expires August 29, 2007 [Page 15]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
Protocol", RFC 4301, December 2005.
[15] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher
Algorithm and Its Use With IPsec", RFC 4312, December 2005.
[16] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494, June 2006.
[17] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced
Encryption Standard-Cipher-based Message Authentication Code-
Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
[18] 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>.
[19] "The NESSIE project (New European Schemes for Signatures,
Integrity and Encryption)",
<http://www.cosic.esat.kuleuven.ac.be/nessie/>.
[20] Information-technology Promotion Agency (IPA), "Cryptography
Research and Evaluation Committees",
<http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html>.
[21] International Organization for Standardization, "Information
technology - Security techniques - Encryption algorithms - Part
3: Block ciphers", ISO/IEC 18033-3, July 2005.
Kato, et al. Expires August 29, 2007 [Page 16]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 February 2007
URIs
[22] <http://info.isl.ntt.co.jp/crypt/eng/camellia/source.html>
[23] <http://info.isl.ntt.co.jp/camellia/>
Kato, et al. Expires August 29, 2007 [Page 17]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 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
Tetsu Iwata
Nagoya University
Email: iwata@cse.nagoya-u.ac.jp
Kato, et al. Expires August 29, 2007 [Page 18]
Internet-Draft The Camellia CMAC-96 and CMAC-PRF-128 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, et al. Expires August 29, 2007 [Page 19]