One document matched: draft-kato-ipsec-camellia-cmac96and128-01.xml


<?xml version="1.0"?>
<?rfc symrefs='no'?>
<?rfc sortrefs='no'?>
<?rfc toc='yes'?>
<?rfc strict='no'?>

<!DOCTYPE rfc SYSTEM 'rfc2119.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4312.dtd' [
<!ENTITY rfc4312 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4312.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4132.dtd' [
<!ENTITY rfc4132 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4132.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc3657.dtd' [
<!ENTITY rfc3657 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3657.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4301.dtd' [
<!ENTITY rfc4301 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4302.dtd' [
<!ENTITY rfc4302 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4306.dtd' [
<!ENTITY rfc4306 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc2411.dtd' [
<!ENTITY rfc2411 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2411.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4051.dtd' [
<!ENTITY rfc4051 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4051.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4086.dtd' [
<!ENTITY rfc4086 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc3713.dtd' [
<!ENTITY rfc3713 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3713.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4494.dtd' [
<!ENTITY rfc4494 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4494.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4615.dtd' [
<!ENTITY rfc4615 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4615.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc4303.dtd' [
<!ENTITY rfc4303 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml'>
]>
<!DOCTYPE rfc SYSTEM 'rfc2409.dtd' [
<!ENTITY rfc2409 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml'>
]>


<rfc ipr="full3978" category="std" docName="draft-kato-ipsec-camellia-cmac96and128-01">


 <front>
   <title abbrev="The Camellia CMAC-96 and CMAC-PRF-128">
    The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use with IPsec
   </title>
    <author initials="A." surname="Kato"
            fullname="Akihiro Kato">
     <organization>
     NTT Software Corporation
     </organization>
    <address>

    <phone>+81-45-212-7577</phone>
    <facsimile>+81-45-212-9800</facsimile>
    <email>akato@po.ntts.co.jp</email>
    </address>
    </author>

    <author initials="M." surname="Kanda"
            fullname="Masayuki Kanda">
     <organization>
     Nippon Telegraph and Telephone Corporation
     </organization>
    <address>
    <phone>+81-422-59-3456</phone>
    <facsimile>+81-422-59-4015 </facsimile>
    <email>kanda.masayuki@lab.ntt.co.jp</email>
    </address> 
   </author>
    <author initials="T." surname="Iwata"
            fullname="Tetsu Iwata">
     <organization>
     Nagoya University
     </organization>
    <address>
    <email>iwata@cse.nagoya-u.ac.jp</email>
    </address>
   </author>
<!-- make formatting date -->
   <date/>

    <area>Security</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Request for Comments</keyword>
    <keyword>IPsec</keyword>
    <keyword>Camellia</keyword>
    <keyword>Block Cipher</keyword>
    <keyword>PRF</keyword>
    <keyword>MAC</keyword>
<abstract>
<t>
   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 pseudo-random function based on CMAC with Camellia block 
   cipher for Internet Key Exchange. This algoritm is called Camellia-CMAC-PRF-128.
</t>
</abstract>

  </front>

<middle>
    <section anchor="intro" title="Introduction">

<t>
   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) <xref target="RFC4303"/> and Authentication Header 
   protocols (AH) <xref target="RFC4302"/>.
   This algorithm is called Camellia-CMAC-96. 
   Latter is Pseudo-Random Function (PRF) based on CMAC with Camellia block 
   cipher for Internet Key Exchange (IKE) <xref target="RFC4306"/>. This 
   algoritm is called Camellia-CMAC-PRF-128.</t>

<t>
   Camellia is a symmetric cipher with a Feistel structure.  Camillia
   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) <xref target="FIPS.197.2001" />.
</t>
<t>
   Camellia supports 128-bit block size and 128-, 192-, and 256-bit key
   lengths, i.e., the same interface specifications as the AES.  
   Therefore developers can implement Camellia based alogorithms  without large amount of 
   modification by replacing AES block of AES based algorithms to Camellia block.

</t>

<t>
   Camellia is adopted as IETF and several international standardization
   organizations.
   Camellia is already adopted as IPSec <xref target="RFC4312" />, 
   TLS <xref target="RFC4132" />, S/MIME <xref target="RFC3657" /> and 
   XML <xref target="RFC4051" />. 

   Camellia is adopted for the one of three ISO/IEC 
   international standard cipher <xref target="ISO/IEC 18033-3" /> 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 <xref target="NESSIE"/> and was included in the list of
   cryptographic techniques for Japanese e-Government systems that was
   selected by the Japan CRYPTREC (Cryptography Research Evaluation
   Committees) <xref target="CRYPTREC" />. 
</t>

<t>
  Since optimized source code is provided by 
  <eref target="http://info.isl.ntt.co.jp/crypt/eng/camellia/source.html" >
  several open source lisences </eref>, 
  Camellia is also adopted by several open source projects(Openssl,
  FreeBSD, Linux and Gran Paradiso).

  Additional API for Network Security Services (NSS) and IPsec stack of 
  Linux and Free BSD are prepared or working progress for release.
  
</t>

   <t>
   The algorithm specification and object identifiers are described in
   <xref target="RFC3713" />.
</t>
<t>
   <eref target="http://info.isl.ntt.co.jp/camellia/">The Camellia homepage</eref>
   contains a wealth of information
   about Camellia, including detailed specification, security analysis,
   performance figures, reference implementation, optimized 
   implementetion, test vectors, and intellectual property information.
</t>
<t>
   This doucment specifies the usage of CMAC with Camellia Block cipher 
   on the authentication mechanism
   of the IPsec Encapsulating Security Payload <xref target="RFC4303"/> and Authentication
   Header <xref target="RFC4302"/> protocols.  This new algorithm is named Camellia-CMAC-96.
</t>
<t>
   NIST CMAC specification document <xref target="CMAC"/> 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 <xref target="RFC4306"/> 
   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 <xref target="RFC4306"/>, 
  <xref target="RFC4302"/>, <xref target="RFC4303"/> and <xref target ="RFC2411"/>.
</t>
<t>
   This document does not cover implementation details of CMAC.
   Those details can be found in <xref target="CMAC"/>.
</t>


<section title="Terminology">
   <t>
   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
   <xref target="RFC2119" />.
</t>
      </section>
    </section>

<section title="Definitions">
<list style="hanging" hangIndent='10'>
    <t hangText="CBC">
     <vspace/>
               Cipher Block Chaining mode of operation for message
               authentication code.
</t>

   <t hangText="MAC">
 <vspace/>
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.</t>

   <t hangText="CMAC">
 <vspace/>         Cipher-based MAC based on a symmetric key
                   block cipher.</t>
   <t hangText="Key (K)">
 <vspace/>         128-bit (16-octet) key for Camellia cipher block.
                   Denoted by K.</t>

   <t hangText="Variable-length Key (VK)">
 <vspace/>         Variable-length key for Camellia-CMAC-PRF-128, denoted
              by VK.
</t>

   <t hangText="Message (M)">
 <vspace/>     Message to be authenticated.
                   Denoted by M.</t>

   <t hangText="Length (len)">
 <vspace/>    The length of message M in octets.
              Denoted by len.
                   The minimum value is 0.  The maximum value is not
                   specified in this document.</t>

   <t hangText="VKlen">
 <vspace/>    The length of VK in octets.
              </t>

   <t hangText="truncate(T,l)">
 <vspace/>   Truncate T (MAC) in most-significant-bit-first
                   (MSB-first) order to a length of l octets.</t>

   <t hangText="T">
 <vspace/>
               The output of Camellia-CMAC.</t>

   <t hangText="Truncated T">
 <vspace/>
     The truncated output of Camellia-CMAC-128 in MSB-first order.</t>

   <t hangText="Camellia-CMAC">
 <vspace/>
        CMAC generation function based on Camellia block cipher
        with 128-bit key.</t>

   <t hangText="Camellia-CMAC-96">
 <vspace/>
     IPsec AH and ESP MAC generation function based on
     Camellia-CMAC, which truncates the 96 most significant
     bits of the 128-bit output.</t>

   <t hangText="Camellia-CMAC-PRF-128">
 <vspace/>
   IPsec AH and ESP PRF based on Camellia-CMAC, which removes 128-bit key 
   length restriction.
</t>
</list>
</section>

<section  title="Camellia-CMAC">
<t>
   The National Institute of Standards and Technology (NIST) has
   recently specified the Cipher-based Message Authentication Code
   (CMAC).  CMAC <xref target="CMAC"/> is a keyed hash function that is based on a
   symmetric key block cipher, such as the Advanced Encryption Standard
   <xref target="FIPS.197.2001"/>. The CMAC algorithm provides a framework for inserting 
   various block cipher algorithm. 
</t>
<t>
   Camellia-CMAC uses the Camellia block cipher <xref target="RFC3713"/> as a
   building block in CMAC <xref target="CMAC"/>.  To generate a MAC, Camelllia-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.
</t>
</section>
<section title="Camellia-CMAC-96">
<t>
   For IPsec message authentication on AH and ESP, Camellia-CMAC-96 MAY be
   used.  Camellia-CMAC-96 is a Camellia-CMAC 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 <xref target="RFC4302"/>.  The result of
   truncation is taken in MSB-first order. 
</t>

<t>
   <xref target="CAM-CMAC96"/> describes Camellia-CMAC-96 algorithm:
</t>
<t>
   In step 1, Camellia-CMAC is applied to the message M in length len with
   key K.
</t>

<t>
   In step 2, the output block T is truncated to 12 octets in MSB-first
   order, and Truncated T (TT) is returned.
</t>

<figure title ="Algorithm Camellia-CMAC-96" anchor="CAM-CMAC96">
<artwork>
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   +                    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  := Camellia-CMAC (K,M,len);                         +
   +   Step 2.  TT := truncate (T, 12);                                +
   +            return TT;                                             +
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
</artwork>
</figure>


</section>

<section title="Camellia-CMAC-PRF-128">
<t>
   The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC  
   except that the 128-bit key length restriction is removed.
</t>
<t>
   IKEv2 <xref target = "RFC4306"/> 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.
</t>
<t>
   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.
</t>
<t>
   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.
</t>

<figure title ="Algorithm Camellia-CMAC-PRF-128" anchor="CMAC-PRF">
<artwork>
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   +                        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 Camellia-CMAC)                       +
   +                                                                   +
   + Step 1.   If VKlen is equal to 16                                 +
   + Step 1a.  then                                                    +
   +               K := VK;                                            +
   + Step 1b.  else                                                    +
   +               K := Camellia-CMAC(0^128, VK, VKlen);               +
   + Step 2.   PRV := Camellia-CMAC(K, M, len);                        +
   +           return PRV;                                             +
   +                                                                   +
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
</artwork>
</figure>
<t>
In step 1, the 128-bit key, K, for Camellia-CMAC is derived as follows:
</t>
<list style="hanging" hangIndent='2'>
   <t hangText="o"> If the key, VK, is exactly 128 bits, then we use it as-is.</t>
<t  hangText="o"> If it is longer or shorter than 128 bits, then we derive the key,
     K, by applying the Camellia-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.
</t>
</list>
<t>
   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 returned.
</t>
</section>
<section title="Test Vectors">

<section title="Camellia-CMAC-96">
<t>
   This section contains four test vectors(TV), which can be used to confirm
   that an implementation has correctly implemented Camellia-CMAC-96.
</t>

<artwork>

 ----------------
 K                2b7e1516 28aed2a6 abf71588 09cf4f3c 

 Mlen = 0
 M                <empty string>
 T                ba925782 aaa1f5d9 a00f8964 

 ----------------
 K                2b7e1516 28aed2a6 abf71588 09cf4f3c 

 Mlen = 16
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
 T                6d962854 a3b9fda5 6d7d45a9 

 ----------------
 K                2b7e1516 28aed2a6 abf71588 09cf4f3c 

 Mlen = 40
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 
 T                5c18d119 ccd67661 44ac1866 

 ----------------
 K                2b7e1516 28aed2a6 abf71588 09cf4f3c 

 Mlen = 64
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 e5fbc119 1a0a52ef 
                  f69f2445 df4f9b17 ad2b417b e66c3710 
 T                c2699a6e ba55ce9d 939a8a4e 
</artwork>
</section>
<section title="Camellia-CMAC-PRF-128">

<t>
   This section contains twelve test vectors(TV), which can be used to confirm
   that an implementation has correctly implemented Camellia-CMAC-PRF-128. The first
   four test vectors use 128 bit VK; the next four test
   vectors use 192 bit VK; and the last four test vectors
   use 256 bit VK.
</t>
<artwork>
VKlen = 16
 ----------------
 VK               2b7e1516 28aed2a6 abf71588 09cf4f3c 


 Mlen = 0
 M                <empty string>
 T                ba925782 aaa1f5d9 a00f8964 8094fc71 

 ----------------
 VK               2b7e1516 28aed2a6 abf71588 09cf4f3c 


 Mlen = 16
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
 T                6d962854 a3b9fda5 6d7d45a9 5ee17993 

 ----------------
 VK               2b7e1516 28aed2a6 abf71588 09cf4f3c 


 Mlen = 40
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 
 T                5c18d119 ccd67661 44ac1866 131d9f22 

 ----------------
 VK               2b7e1516 28aed2a6 abf71588 09cf4f3c 


 Mlen = 64
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 e5fbc119 1a0a52ef 
                  f69f2445 df4f9b17 ad2b417b e66c3710 
 T                c2699a6e ba55ce9d 939a8a4e 19466ee9 

 ------------------------------------------------------------
 VKlen = 24
 ----------------
 VK               8e73b0f7 da0e6452 c810f32b 809079e5 
                  62f8ead2 522c6b7b 

 K                abddaa68 e8b9f0af 2fb4db53 41cf1d91 

 Mlen = 0
 M                <empty string>
 T                f4739892 c70bd23e 891f66c0 5fefbf27 

 ----------------
 VK               8e73b0f7 da0e6452 c810f32b 809079e5 
                  62f8ead2 522c6b7b 

 K                abddaa68 e8b9f0af 2fb4db53 41cf1d91 

 Mlen = 16
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
 T                60a33814 53babaed 1a11dfd3 d24c1410 

 ----------------
 VK               8e73b0f7 da0e6452 c810f32b 809079e5 
                  62f8ead2 522c6b7b 

 K                abddaa68 e8b9f0af 2fb4db53 41cf1d91 

 Mlen = 40
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 
 T                42b9d47f 4f58bc29 85b6f82c 23b121cb 

 ----------------
 VK               8e73b0f7 da0e6452 c810f32b 809079e5 
                  62f8ead2 522c6b7b 

 K                abddaa68 e8b9f0af 2fb4db53 41cf1d91 

 Mlen = 64
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 e5fbc119 1a0a52ef 
                  f69f2445 df4f9b17 ad2b417b e66c3710 
 T                d078729f dcae9abc ff1ea4d6 18ed4501 

 ------------------------------------------------------------
 VKlen = 32
 ----------------
 VK               603deb10 15ca71be 2b73aef0 857d7781 
                  1f352c07 3b6108d7 2d9810a3 0914dff4 

 K                b5aeeae9 2c23bed7 167af194 2e831597 

 Mlen = 0
 M                <empty string>
 T                c96d7d40 d4aaab78 ac906b91 c82bd690 

 ----------------
 VK               603deb10 15ca71be 2b73aef0 857d7781 
                  1f352c07 3b6108d7 2d9810a3 0914dff4 

 K                b5aeeae9 2c23bed7 167af194 2e831597 

 Mlen = 16
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
 T                104de4b9 0da6baf1 fa73945b e614f032 

 ----------------
 VK               603deb10 15ca71be 2b73aef0 857d7781 
                  1f352c07 3b6108d7 2d9810a3 0914dff4 

 K                b5aeeae9 2c23bed7 167af194 2e831597 

 Mlen = 40
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 
 T                2d3684e9 1cb1b303 a7db8648 f25ee16c 

 ----------------
 VK               603deb10 15ca71be 2b73aef0 857d7781 
                  1f352c07 3b6108d7 2d9810a3 0914dff4 

 K                b5aeeae9 2c23bed7 167af194 2e831597 

 Mlen = 64
 M                6bc1bee2 2e409f96 e93d7e11 7393172a 
                  ae2d8a57 1e03ac9c 9eb76fac 45af8e51 
                  30c81c46 a35ce411 e5fbc119 1a0a52ef 
                  f69f2445 df4f9b17 ad2b417b e66c3710 
 T                d6b0f1b7 dda2b62a eca6d51d da63fdda 

</artwork>
</section>
</section>

<section title="Security Considerations">

<t>
   The security provided by Camellia-CMAC-96 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 or CMAC.</t>
<t>
   However, as is true with any
   cryptographic algorithm, part of its strength lies in the secret key,
   K, 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 generated in a
   way that meets the pseudo randomness requirement of RFC 4086
   <xref target = "RFC4086"/> and should be kept safe. 
   If and only if Camellia-CMAC-96 Camellia-CMAC-PRF-128 are used
   properly it provides the authentication and integrity that meet the
   best current practice of message authentication.
</t>
</section>

<section title="IANA Considerations">
<t>
   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.
</t>
</section>
<section title= "Acknowledgements">
<t>
   Portions of this text were borrowed from <xref target="RFC4494"/> and <xref target="RFC4615"/>.  
</t>
</section>
</middle>

<back>

<references title="Normative">

 <reference anchor="CMAC">
 <front>
  <title>Recommendation for Block Cipher Modes of Operation:The CMAC Mode for Autentication</title> 
 <author>
  <organization>National Institute of Standards and Technology</organization> 
  </author>
  <date month="May" year="2005" /> 
  </front>
  <seriesInfo name="Special Publication" value="800-38B" /> 
  </reference>

&rfc2119;
&rfc4302;
&rfc4303;
&rfc4306;
&rfc2411;
&rfc3713;

</references>

<references title="Informative">

&rfc2409;
&rfc3657;
&rfc4051;
&rfc4086;
&rfc4132;
&rfc4301;
&rfc4312;
&rfc4494;
&rfc4615;


 <reference anchor="FIPS.197.2001" target="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf">
 <front>
  <title>Advanced Encryption Standard (AES)</title> 
 <author>
  <organization>National Institute of Standards and Technology</organization> 
  </author>
  <date month="November" year="2001" /> 
  </front>
  <seriesInfo name="FIPS" value="PUB 197" /> 
  </reference>

 <reference anchor="NESSIE" target="http://www.cosic.esat.kuleuven.ac.be/nessie/">
  <front>
  <title abbrev="NESSIE">The NESSIE project (New European Schemes for Signatures, Integrity and Encryption) </title> 
  <author>
  <organization /> 
  </author>
  </front>
 </reference>

 <reference anchor="CRYPTREC" target="http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html" >
  <front>
  <title>Cryptography Research and Evaluation Committees</title> 
  <author fullname="Information-technology Promotion Agency (IPA)">
  <organization>Information-technology Promotion Agency (IPA)</organization> 
  <address>
  <postal>
  <street/>
  <country>Japan</country> 
  </postal>
  </address>
  </author>
  </front>
  <format type="HTML" target="http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html." /> 
 </reference>

 <reference anchor="ISO/IEC 18033-3">
 <front>
  <title>Information technology - Security techniques - Encryption algorithms - Part 3: Block ciphers</title> 
 <author>
  <organization>International Organization for Standardization</organization> 
  </author>
  <date month="July" year="2005" /> 
  </front>
  <seriesInfo name="ISO/IEC" value="18033-3" /> 
  </reference>

</references>
</back>
 </rfc>
 

PAFTECH AB 2003-20262026-04-24 06:03:07