< draft-kato-ipsec-camellia-cmac96and128-04.txt   draft-kato-ipsec-camellia-cmac96and128-05.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: June 24, 2010 M. Kanda
NTT NTT
T. Iwata T. Iwata
Nagoya University Nagoya University
September 9, 2009 December 21, 2009
The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use
with IPsec with IPsec
draft-kato-ipsec-camellia-cmac96and128-04 draft-kato-ipsec-camellia-cmac96and128-05
Abstract
This memo specifies two new algorithms for IPsec. One is the usage
of Cipher-based Message Authentication Code (CMAC) with the Camellia
block cipher as an authentication mechanism in the IPsec
Encapsulating Security Payload and Authentication Header protocols.
This algorithm is called Camellia-CMAC-96. The other algorithm is a
pseudo-random function (PRF) based on CMAC with the Camellia block
cipher for the Internet Key Exchange, version 2. This algorithm is
called Camellia-CMAC-PRF-128.
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 June 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 memo specifies two new algorithms. One is the usage of Cipher- This document may contain material from IETF Documents or IETF
based Message Authentication Code (CMAC) with Camellia block cipher Contributions published or made publicly available before November
on the authentication mechanism of the IPsec Encapsulating Security 10, 2008. The person(s) controlling the copyright in some of this
Payload and Authentication Header protocols. This algorithm is material may not have granted the IETF Trust the right to allow
called Camellia-CMAC-96. Latter is pseudo-random function based on modifications of such material outside the IETF Standards Process.
CMAC with Camellia block cipher for Internet Key Exchange. This Without obtaining an adequate license from the person(s) controlling
algorithm is called Camellia-CMAC-PRF-128. 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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Camellia-CMAC . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Camellia-CMAC . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . . . 8 4. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . . . 8
5. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . . . 9 5. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . . . 9
6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . 11 6.1. Camellia-CMAC-96 . . . . . . . . . . . . . . . . . . . . . 11
6.2. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . 11 6.2. Camellia-CMAC-PRF-128 . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This memo specifies two new algorithms. One is the usage of CMAC The NIST specification [1] for the CMAC (Cipher-based Message
based on Camellia block cipher on the authentication mechanism of the Authentication Code) mode of operation for a block cipher describes a
IPsec Encapsulating Security Payload (ESP) [6] and Authentication method to use the Advanced Encryption Standard (AES) as a Message
Header protocols (AH) [5]. This algorithm is called Authentication Code (MAC) that has a 128-bit output length.
Camellia-CMAC-96. Latter is Pseudo-Random Function (PRF) based on
CMAC with Camellia block cipher for Internet Key Exchange (IKEv2)
[7]. This algorithm is called Camellia-CMAC-PRF-128.
The algorithm specification and object identifiers are described in
[3].
This document specifies the usage of CMAC with Camellia Block cipher
on the authentication mechanism of the IPsec Encapsulating Security
Payload [6] and Authentication Header [5] 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 PRF. This document also specifies a PRF based on
CMAC with Camellia block cipher that supports fixed and variable key
sizes for IKEv2 [7] Key Derivation Function (KDF) and authentication.
This new algorithm is named Camellia-CMAC-PRF-128. For further
information on IKE, AH and ESP, refer to [7], [5], [6], and [4].
This document does not cover implementation details of CMAC. Those
details can be found in [1].
1.1. Terminology The Camellia block cipher has the same external interface as the AES.
This memo specifies two new algorithms for IPsec that replace AES by
Camellia in already specified applications of CMAC for IPsec [8] and
[9]. One is the usage of CMAC mode with Camellia [2] as the
underlying block cipher as an authentication mechanism in the IPsec
Encapsulating Security Payload (ESP) [5] and Authentication Header
(AH) [4] protocols. This algorithm is called Camellia-CMAC-96. The
128-bit CMAC output is also useful as a long-lived Pseudo-Random
Function (PRF). Thus, the other algorithm is a PRF based on CMAC
with the Camellia block cipher for version 2 of the Internet Key
Exchange (IKEv2) [6] that supports fixed and variable key sizes for
the Key Derivation Function (KDF) and authentication, respectively.
This algorithm is called Camellia-CMAC-PRF-128.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The Camellia algorithm and its properties are described in [2]. This
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document does not cover implementation details of CMAC. Those
document are to be interpreted as described in [2]. details can be found in [1]. For further information on IKE, AH and
ESP, refer to [3], [4], [5], and [6].
2. Definitions 2. Definitions
CBC CBC
Cipher Block Chaining mode of operation for message Cipher Block Chaining mode of operation for a block cipher,
authentication code. providing a block cipher for arbitrary message sizes.
MAC MAC
Message Authentication Code. A bit string of a fixed Message Authentication Code. A bit string of a fixed
length, computed by the MAC generation algorithm, that is length, computed by the MAC generation algorithm, that is
used to establish the authority and, hence, the integrity used to establish the authority and, hence, the integrity
of a message. of a message.
CMAC CMAC
Cipher-based MAC based on a symmetric key block cipher. A MAC algorithm based on a symmetric key block cipher in
CBC mode, as specified in [1].
Key (K) Key (K)
128-bit (16-octet) key for Camellia cipher block. Denoted 128-bit (16-octet) key for the Camellia block cipher.
by K. Denoted by K.
Variable-length Key (VK) Variable-length Key (VK)
Variable-length key for Camellia-CMAC-PRF-128, denoted by Variable-length key for Camellia-CMAC-PRF-128, denoted by
VK. VK.
Message (M) Message (M)
Message to be authenticated. Denoted by M. Message to be authenticated. Denoted by M.
Length (len) Length (len)
The length of message M in octets. Denoted by len. The The length of message M in octets. Denoted by len. The
skipping to change at page 5, line 47 skipping to change at page 5, line 48
The length of VK in octets. The length of VK in octets.
truncate(T,l) truncate(T,l)
Truncate T (MAC) in most-significant-bit-first (MSB-first) Truncate T (MAC) in most-significant-bit-first (MSB-first)
order to a length of l octets. order to a length of l octets.
T T
The output of Camellia-CMAC. The output of Camellia-CMAC.
Camellia-CMAC Camellia-CMAC
CMAC generation function based on Camellia block cipher CMAC generation function based on the Camellia block cipher
with 128-bit key. with 128-bit key.
Camellia-CMAC-96 Camellia-CMAC-96
IPsec AH and ESP MAC generation function based on Camellia- IPsec AH and ESP MAC generation function based on Camellia-
CMAC, which truncates the 96 most significant bits of the CMAC, which truncates the 128-bit CMAC output to its 96
128-bit output. most-significant bits.
Camellia-CMAC-PRF-128 Camellia-CMAC-PRF-128
IPsec AH and ESP PRF based on Camellia-CMAC, which removes IPsec AH and ESP PRF based on Camellia-CMAC, which removes
128-bit key length restriction. the 128-bit key length restriction.
SKEYSEED Seed of shared key calculated from the nonces exchanged SKEYSEED
Seed of shared key calculated from the nonces exchanged
during the IKE_SA_INIT exchange and the Diffie-Hellman during the IKE_SA_INIT exchange and the Diffie-Hellman
shared secret in IKEv2 specification. shared secret in the IKEv2 specification [6].
3. Camellia-CMAC 3. Camellia-CMAC
The National Institute of Standards and Technology (NIST) has The National Institute of Standards and Technology (NIST) has
recently specified the Cipher-based Message Authentication Code specified the Cipher-based Message Authentication Code (CMAC) [1].
(CMAC). CMAC [1] is a keyed hash function that is based on a CMAC is a keyed hash function that is based on a symmetric key block
symmetric key block cipher, such as the Advanced Encryption Standard cipher, such as the Advanced Encryption Standard [10]. The CMAC
[9]. The CMAC algorithm provides a framework for inserting various algorithm provides a framework for inserting various block cipher
block cipher algorithm. algorithms.
Camellia-CMAC uses the Camellia block cipher [3] as a building block Camellia-CMAC uses the Camellia block cipher [2] as a building block
in CMAC [1]. To generate a MAC, Camellia-CMAC(K, M, len) takes a in CMAC [1]. To generate a MAC, Camellia-CMAC(K, M, len) takes a
secret key 'K', a message of variable length 'M', and the length of secret key 'K', a message of variable length 'M', and the length of
the message in octets 'len' as inputs and returns a fixed-bit string. the message in octets 'len' as inputs and returns a fixed-length bit
string.
In this specification, Camellia-CMAC is always used with 128-bit In this specification, Camellia-CMAC is always used with 128-bit
length key. length key.
4. Camellia-CMAC-96 4. Camellia-CMAC-96
For IPsec message authentication on AH and ESP, Camellia-CMAC-96 MAY For IPsec message authentication in AH and ESP, Camellia-CMAC is used
be used. Camellia-CMAC-96 is a Camellia-CMAC with 96-bit truncated in its truncated form denoted as Camellia-CMAC-96 -- Camellia-CMAC
output in MSB-first order. The output is a 96-bit MAC that will meet with its output truncated to 96 bits. Its output is a 96-bit MAC
the default authenticator length as specified in [5]. The result of that meets the default authenticator length as specified in [4]. The
truncation is taken in MSB-first order. result of truncation is taken in MSB-first order.
Figure 1 describes Camellia-CMAC-96 algorithm: Figure 1 describes Camellia-CMAC-96 algorithm:
In step 1, Camellia-CMAC is applied to the message M in length len In step 1, Camellia-CMAC with key K is applied to the message M of
with key K. length len octets.
In step 2, the output block T is truncated to 12 octets in MSB-first In step 2, the output of step 1 is truncated to its first 12 octets,
order, and Truncated T (TT) is returned. and the result (TT) is returned.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Algorithm Camellia-CMAC-96 + + Algorithm Camellia-CMAC-96 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ + + +
+ Input : K (128-bit Key) + + Input : K (128-bit Key) +
+ : M (message to be authenticated) + + : M (message to be authenticated) +
+ : len (length of message in octets) + + : len (length of message in octets) +
+ Output : Truncated T (truncated output to length 12 octets) + + Output : Truncated T (truncated output to length 12 octets) +
+ + + +
skipping to change at page 9, line 10 skipping to change at page 9, line 10
+ return TT; + + return TT; +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1: Algorithm Camellia-CMAC-96 Figure 1: Algorithm Camellia-CMAC-96
5. Camellia-CMAC-PRF-128 5. Camellia-CMAC-PRF-128
The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC
except that the 128-bit key length restriction is removed. except that the 128-bit key length restriction is removed.
IKEv2 [7] uses PRFs for multiple purposes, most notably for IKEv2 [6] uses PRFs for multiple purposes, most notably for
generating keying material and authentication of the IKE_SA. generating keying material and authentication of the IKE_SA.
When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2, When using Camellia-CMAC-PRF-128 as the PRF described in [6],
Camellia-CMAC-PRF-128 is considered to take variable key length in Camellia-CMAC-PRF-128 is considered to admit a variable key length in
all places, and the number of bits of keying material generated when all places, and the amount of keying material generated when new keys
new keys are generated is 128 bits (i.e. preferred key length when are generated is 128 bits (i.e., preferred key length when generating
generating keying material of SK_d, SK_pi, and SK_pr is 128 bits). keying material of SK_d, SK_pi, and SK_pr is 128 bits).
When generating SKEYSEED the full of Ni and Nr are used as key for When generating SKEYSEED the full of Ni and Nr are used as key for
the PRF. the PRF.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Camellia-CMAC-PRF-128 + + Camellia-CMAC-PRF-128 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ + + +
+ Input : VK (Variable-length key) + + Input : VK (Variable-length key) +
+ : M (Message, i.e., the input data of the PRF) + + : M (Message, i.e., the input data of the PRF) +
skipping to change at page 10, line 5 skipping to change at page 10, line 5
+ Step 2. PRV := Camellia-CMAC(K, M, len); + + Step 2. PRV := Camellia-CMAC(K, M, len); +
+ return PRV; + + return PRV; +
+ + + +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 2: Algorithm Camellia-CMAC-PRF-128 Figure 2: Algorithm Camellia-CMAC-PRF-128
In step 1, the 128-bit key, K, for Camellia-CMAC is derived as In step 1, the 128-bit key, K, for Camellia-CMAC is derived as
follows: follows:
o If the key, VK, is exactly 128 bits, then we use it as-is. o If the key VK is exactly 128 bits, then we use it as-is (step 1a).
o If it is longer or shorter than 128 bits, then we derive the key, o If it is longer or shorter than 128 bits, then we derive the key K
K, by applying the Camellia-CMAC algorithm using the 128-bit all- by applying the Camellia-CMAC algorithm using the 128-bit all-zero
zero string as the key and VK as the input message. This step is string as the key and VK as the input message (step 1b).
described in step 1b.
In step 2, we apply the Camellia-CMAC algorithm using K as the key In step 2, we apply the Camellia-CMAC algorithm using K as the key
and M as the input message. The output of this algorithm is and M as the input message. The output of this algorithm is
returned. returned.
6. Test Vectors 6. Test Cases
6.1. Camellia-CMAC-96 6.1. Camellia-CMAC-96
This section contains four test vectors(TV), which can be used to This section contains four test cases, which can be used to confirm
confirm that an implementation has correctly implemented Camellia- that an implementation has correctly implemented Camellia-CMAC-96.
CMAC-96.
---------------- ----------------
K 2b7e1516 28aed2a6 abf71588 09cf4f3c K 2b7e1516 28aed2a6 abf71588 09cf4f3c
Mlen = 0 Mlen = 0
M <empty string> M <empty string>
T ba925782 aaa1f5d9 a00f8964 T ba925782 aaa1f5d9 a00f8964
---------------- ----------------
K 2b7e1516 28aed2a6 abf71588 09cf4f3c K 2b7e1516 28aed2a6 abf71588 09cf4f3c
skipping to change at page 11, line 48 skipping to change at page 11, line 47
Mlen = 64 Mlen = 64
M 6bc1bee2 2e409f96 e93d7e11 7393172a M 6bc1bee2 2e409f96 e93d7e11 7393172a
ae2d8a57 1e03ac9c 9eb76fac 45af8e51 ae2d8a57 1e03ac9c 9eb76fac 45af8e51
30c81c46 a35ce411 e5fbc119 1a0a52ef 30c81c46 a35ce411 e5fbc119 1a0a52ef
f69f2445 df4f9b17 ad2b417b e66c3710 f69f2445 df4f9b17 ad2b417b e66c3710
T c2699a6e ba55ce9d 939a8a4e T c2699a6e ba55ce9d 939a8a4e
6.2. Camellia-CMAC-PRF-128 6.2. Camellia-CMAC-PRF-128
This section contains twelve test vectors(TV), which can be used to This section contains twelve test cases, which can be used to confirm
confirm that an implementation has correctly implemented Camellia- that an implementation has correctly implemented Camellia-CMAC-PRF-
CMAC-PRF-128. The first four test vectors use 128 bit VK; the next 128. The first four test cases use 128 bit VK; the next four test
four test vectors use 192 bit VK; and the last four test vectors use cases use 192 bit VK; and the last four test cases use 256 bit VK.
256 bit VK.
VKlen = 16 VKlen = 16
---------------- ----------------
VK 2b7e1516 28aed2a6 abf71588 09cf4f3c VK 2b7e1516 28aed2a6 abf71588 09cf4f3c
Mlen = 0 Mlen = 0
M <empty string> M <empty string>
T ba925782 aaa1f5d9 a00f8964 8094fc71 T ba925782 aaa1f5d9 a00f8964 8094fc71
---------------- ----------------
skipping to change at page 15, line 7 skipping to change at page 15, line 7
Mlen = 64 Mlen = 64
M 6bc1bee2 2e409f96 e93d7e11 7393172a M 6bc1bee2 2e409f96 e93d7e11 7393172a
ae2d8a57 1e03ac9c 9eb76fac 45af8e51 ae2d8a57 1e03ac9c 9eb76fac 45af8e51
30c81c46 a35ce411 e5fbc119 1a0a52ef 30c81c46 a35ce411 e5fbc119 1a0a52ef
f69f2445 df4f9b17 ad2b417b e66c3710 f69f2445 df4f9b17 ad2b417b e66c3710
T d6b0f1b7 dda2b62a eca6d51d da63fdda T d6b0f1b7 dda2b62a eca6d51d da63fdda
7. Security Considerations 7. Security Considerations
The security provided by Camellia-CMAC-96 Camellia-CMAC-PRF-128 is The security provided by Camellia-CMAC-96 and Camellia-CMAC-PRF-128
built on the strong cryptographic algorithm Camellia and CMAC. At is built on the strong cryptographic algorithm Camellia and CMAC. At
the time of this writing, there are no known practical cryptographic the time of this writing, there are no known practical cryptographic
attacks against Camellia or CMAC. attacks against Camellia or CMAC.
However, as is true with any cryptographic algorithm, part of its However, as is true with any cryptographic algorithm, part of its
strength lies in the secret key, K, and the correctness of the strength lies in the secret key, K, and the correctness of the
implementation in all of the participating systems. If the secret implementation in all of the participating systems. If the secret
key is compromised or inappropriately shared, it guarantees neither key is compromised or inappropriately shared, it guarantees neither
authentication nor integrity of message at all. The secret key shall authentication nor message integrity at all. The secret key shall be
be generated in a way that meets the pseudo randomness requirement of generated in a way that meets the pseudo randomness requirement of
RFC 4086 [8] and should be kept safe. If and only if RFC 4086 [7] and should be kept safe. If and only if
Camellia-CMAC-96 Camellia-CMAC-PRF-128 are used properly it provides Camellia-CMAC-96 and Camellia-CMAC-PRF-128 are used properly it
the authentication and integrity that meet the best current practice provides the authentication and integrity that meet the best current
of message authentication. practice of message authentication.
8. IANA Considerations 8. IANA Considerations
The IANA has allocated value <TBD1> for IKEv2 Transform Type 3 The IANA has allocated value <TBD1> for IKEv2 Transform Type 3
(Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has (Integrity Algorithm) to the AUTH_CAMELLIA_CMAC_96 algorithm, and has
allocated a value of <TBD2> for IKEv2 Transform Type 2 (Pseudo-Random allocated a value of <TBD2> for IKEv2 Transform Type 2 (Pseudo-Random
Function) to the PRF_CAMELLIA128_CMAC algorithm. Function) to the PRF_CAMELLIA128_CMAC algorithm.
9. Acknowledgements 9. Acknowledgements
We thank Tim Polk and Tero Kivinen for their initial review of this We thank Tim Polk and Tero Kivinen for their initial review of this
document. document. Special thanks to Alfred Hoenes for several very detailed
reviews and suggestions.
10. References 10. References
10.1. Normative 10.1. Normative
[1] National Institute of Standards and Technology, "Recommendation [1] National Institute of Standards and Technology, "Recommendation
for Block Cipher Modes of Operation:The CMAC Mode for for Block Cipher Modes of Operation:The CMAC Mode for
Authentication", Special Publication 800-38B, May 2005. Authentication", 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] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the [2] 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.
10.2. Informative 10.2. Informative
[4] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document [3] Kent, S. and K. Seo, "Security Architecture for the Internet
Roadmap", RFC 2411, November 1998. Protocol", RFC 4301, December 2005.
[5] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [4] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005. December 2005.
[7] Kaufman, C., Hoffman, P., and P. Eronen, "Internet Key Exchange [6] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
Protocol: IKEv2", draft-hoffman-ikev2bis-03 (work in progress), Exchange Protocol: IKEv2", draft-ietf-ipsecme-ikev2bis-06 (work
February 2008. in progress), December 2009.
[8] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [7] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[9] National Institute of Standards and Technology, "Advanced [8] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Encryption Standard (AES)", FIPS PUB 197, November 2001, Algorithm and Its Use with IPsec", RFC 4494, June 2006.
<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[9] Gustin, J. and A. Goyens, "A Uniform Resource Name (URN)
Namespace for SWIFT Financial Messaging", RFC 3615,
September 2003.
[10] 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>.
Authors' Addresses Authors' Addresses
Akihiro Kato Akihiro Kato
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: 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-422-59-3456 Phone: +81-422-59-3456
Fax: +81-422-59-4015 Fax: +81-422-59-4015
Email: kanda.masayuki@lab.ntt.co.jp Email: kanda.masayuki@lab.ntt.co.jp
 End of changes. 47 change blocks. 
140 lines changed or deleted 142 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/