[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5529

Network Working Group                                            A. Kato
Internet-Draft                                  NTT Software Corporation
Intended status: Standards Track                                M. Kanda
Expires: May 16, 2007                     Nippon Telegraph and Telephone
                                                             Corporation
                                                       November 12, 2006


 The Additional Modes of Operation for Camellia and Its Use With IPsec
                   draft-kato-ipsec-camellia-modes-01

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 May 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).












Kato & Kanda              Expires May 16, 2007                  [Page 1]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


Abstract

   This document describes the use of the Camellia block cipher
   algorithm in Counter mode and Counter with CBC-MAC (CCM) Mode , as an
   IPsec Encapsulating Security Payload (ESP) mechanism to provide
   confidentiality, data origin authentication, and connectionless
   integrity.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Camellia Cipher Algorithm  . . . . . . . . . . . . . . . .  4
     2.1.  Key Size . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Weak Keys  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Block Size and Padding . . . . . . . . . . . . . . . . . .  4
     2.4.  Performance  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Counter  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Counter with CBC MAC . . . . . . . . . . . . . . . . . . .  8
   4.  ESP Payload  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Counter  . . . . . . . . . . . . . . . . . . . . . . . . . 11
       4.1.1.  Counter Block Format . . . . . . . . . . . . . . . . . 12
       4.1.2.  Keying Material  . . . . . . . . . . . . . . . . . . . 13
     4.2.  Counter with CBC MAC . . . . . . . . . . . . . . . . . . . 13
       4.2.1.  Initialization Vector (IV) . . . . . . . . . . . . . . 13
       4.2.2.  Encrypted Payload  . . . . . . . . . . . . . . . . . . 14
       4.2.3.  Authentication Data  . . . . . . . . . . . . . . . . . 14
       4.2.4.  Nonce Format . . . . . . . . . . . . . . . . . . . . . 14
       4.2.5.  AAD Construction . . . . . . . . . . . . . . . . . . . 15
   5.  IKE Conventions  . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . 17
     5.2.  Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . 17
     5.3.  Key Length Attribute . . . . . . . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25









Kato & Kanda              Expires May 16, 2007                  [Page 2]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


1.  Introduction

   This document describes the use of the Camellia block cipher
   algorithm in Counter mode and Counter with CBC-MAC (CCM) Mode , as an
   IPsec Encapsulating Security Payload (ESP) mechanism to provide
   confidentiality, data origin authentication, and connectionless
   integrity.

   Camellia is adopted as IETF and several international standardization
   organizations.  Camellia is already adopted as IPSec[Camellia-IPsec],
   TLS[Camellia-TLS], and S/MIME[Camellia-SMIME] .  Camellia was
   selected as a recommended cryptographic primitive by the EU NESSIE
   (New European Schemes for Signatures, Integrity and Encryption)
   project [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)
   [CRYPTREC].  Camellia is also adopted for the ISO/IEC international
   standard cipher [ISO/IEC 18033-3].

   Camellia supports 128-bit block size and 128-, 192-, and 256-bit key
   lengths, i.e., the same interface specifications as the Advanced
   Encryption Standard [AES].

   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 AES.

   The Camellia homepage The Camellia homepage [1] contains a wealth of
   information about camellia, including detailed specification,
   security analysis, performance figures, reference implementation,
   test vectors, and intellectual property information.

   The remainder of this document specifies the Addtional modes of
   operation Camellia within the context of IPsec ESP.  For further
   information on how the various pieces of ESP fit together to provide
   security services, please refer to [ARCH] [ESP], and [ROADMAP].

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
   [RFC2119].




Kato & Kanda              Expires May 16, 2007                  [Page 3]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


2.  The Camellia Cipher Algorithm

   All symmetric block cipher algorithms share common characteristics
   and variables, including mode, key size, weak keys, block size, and
   rounds.  The following sections contain descriptions of the relevant
   characteristics of Camellia.

   The algorithm specification and object identifiers are described in
   [Camellia-Desc].

2.1.  Key Size

   Camellia supports three key sizes: 128 bits, 192 bits, and 256 bits.
   The default key size is 128 bits, and all implementations MUST
   support this key size.  Implementations MAY also support key sizes of
   192 bits and 256 bits.

   Camellia uses a different number of rounds for each of the defined
   key sizes.  When a 128-bit key is used, implementations MUST use 18
   rounds.  When a 192-bit key is used, implementations MUST use 24
   rounds.  When a 256-bit key is used, implementations MUST use 24
   rounds.

2.2.  Weak Keys

   At the time of writing this document there are no known weak keys for
   Camellia.

2.3.  Block Size and Padding

   Camellia uses a block size of sixteen octets (128 bits).

   Padding is required by the algorithms to maintain a 16-octet (128-
   bit) block size.  Padding MUST be added, as specified in [ESP], such
   that the data to be encrypted (which includes the ESP Pad Length and
   Next Header fields) has a length that is a multiple of 16 octets.

   Because of the algorithm specific padding requirement, no additional
   padding is required to ensure that the ciphertext terminates on a
   4-octet boundary (i.e. maintaining a 16-octet block size guarantees
   that the ESP Pad Length and Next Header fields will be right aligned
   within a 4-octet word).  Additional padding MAY be included, as
   specified in [ESP], as long as the 16-octet block size is maintained.

2.4.  Performance

   Performance figures of Camellia are available at
   <http://info.isl.ntt.co.jp/camellia/>.  It also includes performance



Kato & Kanda              Expires May 16, 2007                  [Page 4]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   comparison with the AES cipher and other AES finalists.  NESSIE
   project has reported performance of Optimized Implementations
   independently [NESSIE].
















































Kato & Kanda              Expires May 16, 2007                  [Page 5]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


3.  Mode

   NIST has defined five modes of operation for AES and other FIPS-
   approved block ciphers [MODES].  Each of these modes has different
   characteristics.  The five modes are: ECB (Electronic Code Book), CBC
   (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output
   FeedBack), and CTR (Counter).

   CCM is a generic authenticate-and-encrypt block cipher mode [CCM].
   In this specification, CCM is used with the Camellia [Camellia-Desc]
   block cipher.

   Camellia Counter mode (Camellia-CTR) and Camellia Counter with CBC-
   MAC (Camellia-CCM) are discussed in this specification.

3.1.  Counter

   Camellia-CTR requires the encryptor to generate a unique per-packet
   value, and communicate this value to the decryptor.  This
   specification calls this per-packet value an initialization vector
   (IV).  The same IV and key combination MUST NOT be used more than
   once.  The encryptor can generate the IV in any manner that ensures
   uniqueness.  Common approaches to IV generation include incrementing
   a counter for each packet and linear feedback shift registers
   (LFSRs).

   This specification calls for the use of a nonce for additional
   protection against precomputation attacks.  The nonce value need not
   be secret.  However, the nonce MUST be unpredictable prior to the
   establishment of the IPsec security association that is making use of
   Camellia-CTR.

   Camellia-CTR has many properties that make it an attractive
   encryption algorithm for in high-speed networking.  Camellia-CTR uses
   the Camellia block cipher to create a stream cipher.  Data is
   encrypted and decrypted by XORing with the key stream produced by
   Camellia encrypting sequential counter block values.  Camellia-CTR is
   easy to implement, and Camellia-CTR can be pipelined and
   parallelized.  Camellia-CTR also supports key stream precomputation.

   Pipelining is possible because Camellia has multiple rounds (see
   section Section 2.).  A hardware implementation (and some software
   implementations) can create a pipeline by unwinding the loop implied
   by this round structure.  For example, after a 16-octet block has
   been input, one round later another 16-octet block can be input, and
   so on.  In Camellia- CTR, these inputs are the sequential counter
   block values used to generate the key stream.




Kato & Kanda              Expires May 16, 2007                  [Page 6]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   Multiple independent Camellia encrypt implementations can also be
   used to improve performance.  For example, one could use two Camellia
   encrypt implementations in parallel, to process a sequence of counter
   block values, doubling the effective throughput.

   The sender can precompute the key stream.  Since the key stream does
   not depend on any data in the packet, the key stream can be
   precomputed once the nonce and IV are assigned.  This precomputation
   can reduce packet latency.  The receiver cannot perform similar
   precomputation because the IV will not be known before the packet
   arrives.

   Camellia-CTR uses the only Camellia encrypt operation (for both
   encryption and decryption), making Camellia-CTR implementations
   smaller than implementations of many other Camellia modes.

   When used correctly, Camellia-CTR provides a high level of
   confidentiality.  Unfortunately, Camellia-CTR is easy to use
   incorrectly.  Being a stream cipher, any reuse of the per-packet
   value, called the IV, with the same nonce and key is catastrophic.
   An IV collision immediately leaks information about the plaintext in
   both packets.  For this reason, it is inappropriate to use this mode
   of operation with static keys.  Extraordinary measures would be
   needed to prevent reuse of an IV value with the static key across
   power cycles.  To be safe, implementations MUST use fresh keys with
   Camellia-CTR.  The Internet Key Exchange (IKE) [IKE] protocol can be
   used to establish fresh keys.  IKE can also provide the nonce value.

   With Camellia-CTR, it is trivial to use a valid ciphertext to forge
   other (valid to the decryptor) ciphertexts.  Thus, it is equally
   catastrophic to use Camellia-CTR without a companion authentication
   function.  Implementations MUST use Camellia-CTR in conjunction with
   an authentication function, such as HMAC-SHA-1-96 [HMAC-SHA].

   To encrypt a payload with Camellia-CTR, the encryptor partitions the
   plaintext, PT, into 128-bit blocks.  The final block need not be 128
   bits; it can be less.

         PT = PT[1] PT[2] ... PT[n]

   Each PT block is XORed with a block of the key stream to generate the
   ciphertext, CT.  The Camellia encryption of each counter block
   results in 128 bits of key stream.  The most significant 96 bits of
   the counter block are set to the nonce value, which is 32 bits,
   followed by the per-packet IV value, which is 64 bits.  The least
   significant 32 bits of the counter block are initially set to one.
   This counter value is incremented by one to generate subsequent
   counter blocks, each resulting in another 128 bits of key stream.



Kato & Kanda              Expires May 16, 2007                  [Page 7]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   The encryption of n plaintext blocks can be summarized as:

         CTRBLK := NONCE || IV || ONE
         FOR i := 1 to n-1 DO
           CT[i] := PT[i] XOR Camellia(CTRBLK)
           CTRBLK := CTRBLK + 1
         END
         CT[n] := PT[n] XOR TRUNC(Camellia(CTRBLK))

   The Camellia() function performs Camellia encryption with the fresh
   key.

   The TRUNC() function truncates the output of the Camellia encrypt
   operation to the same length as the final plaintext block, returning
   the most significant bits.

   Decryption is similar.  The decryption of n ciphertext blocks can be
   summarized as:


         CTRBLK := NONCE || IV || ONE
         FOR i := 1 to n-1 DO
           PT[i] := CT[i] XOR Camellia(CTRBLK)
           CTRBLK := CTRBLK + 1
         END
         PT[n] := CT[n] XOR TRUNC(Camellia(CTRBLK))

3.2.  Counter with CBC MAC

   CCM is a generic authenticate-and-encrypt block cipher mode [CCM].
   In this specification, CCM is used with the Camellia [Camellia-Desc]
   block cipher.

   Camellia-CCM has two parameters:

   M  M indicates the size of the integrity check value (ICV).  CCM
      defines values of 4, 6, 8, 10, 12, 14, and 16 octets; However, to
      maintain alignment and provide adequate security, only the values
      that are a multiple of four and are at least eight are permitted.
      Implementations MUST support M values of 8 octets and 16 octets,
      and implementations MAY support an M value of 12 octets.

   L  L indicates the size of the length field in octets.  CCM defines
      values of L between 2 octets and 8 octets.  This specification
      only supports L = 4.  Implementations MUST support an L value of 4
      octets, which accommodates a full Jumbogram [JUMBO]; however, the
      length includes all of the encrypted data, which also includes the
      ESP Padding, Pad Length, and Next Header fields.



Kato & Kanda              Expires May 16, 2007                  [Page 8]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   There are four inputs to CCM originator processing:

   key
      A single key is used to calculate the ICV using CBC-MAC and to
      perform payload encryption using counter mode.  Camellia supports
      key sizes of 128 bits, 192 bits, and 256 bits.  The default key
      size is 128 bits, and implementations MUST support this key size.
      Implementations MAY also support key sizes of 192 bits and 256
      bits.

   nonce
      The size of the nonce depends on the value selected for the
      parameter L. It is 15-L octets.  Implementations MUST support a
      nonce of 11 octets.  The construction of the nonce is described in
      Section 4.2.4.

   payload
      The payload of the ESP packet.  The payload MUST NOT be longer
      than 4,294,967,295 octets, which is the maximum size of a
      Jumbogram [JUMBO]; however, the ESP Padding, Pad Length, and Next
      Header fields are also part of the payload.

   AAD
      CCM provides data integrity and data origin authentication for
      some data outside the payload.  CCM does not allow additional
      authenticated data (AAD) to be longer than
      18,446,744,073,709,551,615 octets.  The ICV is computed from the
      ESP header, Payload, and ESP trailer fields, which is
      significantly smaller than the CCM-imposed limit.  The
      construction of the AAD described in Section 4.2.5.

   Camellia-CCM requires the encryptor to generate a unique per-packet
   value and to communicate this value to the decryptor.  This per-
   packet value is one of the component parts of the nonce, and it is
   referred to as the initialization vector (IV).  The same IV and key
   combination MUST NOT be used more than once.  The encryptor can
   generate the IV in any manner that ensures uniqueness.  Common
   approaches to IV generation include incrementing a counter for each
   packet and linear feedback shift registers (LFSRs).

   Camellia-CCM employs counter mode for encryption.  As with any stream
   cipher, reuse of the same IV value with the same key is catastrophic.
   An IV collision immediately leaks information about the plaintext in
   both packets.  For this reason, it is inappropriate to use this CCM
   with statically configured keys.  Extraordinary measures would be
   needed to prevent reuse of an IV value with the static key across
   power cycles.  To be safe, implementations MUST use fresh keys with
   Camellia-CCM.  The Internet Key Exchange (IKE) [IKE] protocol or



Kato & Kanda              Expires May 16, 2007                  [Page 9]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   IKEv2 [IKEv2] can be used to establish fresh keys.


















































Kato & Kanda              Expires May 16, 2007                 [Page 10]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


4.  ESP Payload

   The ESP payload is made up of the IV followed by raw cipher-text.
   Thus the payload field, as defined in [ESP], is broken down according
   to the following diagram:

4.1.  Counter

   Each packet conveys the IV that is necessary to construct the
   sequence of counter blocks used to generate the key stream necessary
   to decrypt the payload.  The Camellia counter block cipher block is
   128 bits.  Figure 1 shows the format of the counter block.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Initialization Vector                     |
      |                            (8 octets)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                  Encrypted Payload (variable)                 ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                 Authentication Data (variable)                ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: ESP Payload Encrypted with Camellia-CTR

   The components of the counter block are as follows:

   Initialization Vector
      The Camellia-CTR IV field MUST be eight octets.  The IV MUST be
      chosen by the encryptor in a manner that ensures that the same IV
      value is used only once for a given key.  The encryptor can
      generate the IV in any manner that ensures uniqueness.  Common
      approaches to IV generation include incrementing a counter for
      each packet and linear feedback shift registers (LFSRs).
      Including the IV in each packet ensures that the decryptor can
      generate the key stream needed for decryption, even when some
      packets are lost or reordered.

   Encrypted Payload
      The encrypted payload contains the ciphertext.  Camellia-CTR mode
      does not require plaintext padding.  However, ESP does require
      padding to 32-bit word-align the authentication data.  The
      padding, Pad Length, and the Next Header MUST be concatenated with



Kato & Kanda              Expires May 16, 2007                 [Page 11]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


      the plaintext before performing encryption, as described in [ESP].

   Authentication Data
      Since it is trivial to construct a forgery Camellia-CTR ciphertext
      from a valid Camellia-CTR ciphertext, Camellia-CTR implementations
      MUST employ a non- NULL ESP authentication method.  HMAC-SHA-1-96
      [HMAC-SHA] is a likely choice.

4.1.1.  Counter Block Format

   Each packet conveys the IV that is necessary to construct the
   sequence of counter blocks used to generate the key stream necessary
   to decrypt the payload.  The Camellia counter block cipher block is
   128 bits.  Figure 2 shows the format of the counter block.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Nonce                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Initialization Vector (IV)                   |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Block Counter                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: Counter Block Format

   The components of the counter block are as follows:

   Nonce
      The Nonce field is 32 bits.  As the name implies, the nonce is a
      single use value.  That is, a fresh nonce value MUST be assigned
      for each security association.  It MUST be assigned at the
      beginning of the security association.  The nonce value need not
      be secret, but it MUST be unpredictable prior to the beginning of
      the security association.

   Initializetion Vector
      The IV field is 64 bits.  As described in section 3.1, the IV MUST
      be chosen by the encryptor in a manner that ensures that the same
      IV value is used only once for a given key.

   Block Counter
      The block counter field is the least significant 32 bits of the
      counter block.  The block counter begins with the value of one,
      and it is incremented to generate subsequent portions of the key



Kato & Kanda              Expires May 16, 2007                 [Page 12]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


      stream.  The block counter is a 32-bit big-endian integer value.

   Using the encryption process described in Section 3.1, this
   construction permits each packet to consist of up to:

         (2^32)-1 blocks  =  4,294,967,295 blocks
                          = 68,719,476,720 octets

   This construction can produce enough key stream for each packet
   sufficient to handle any IPv6 jumbogram [JUMBO].

4.1.2.  Keying Material

   The minimum number of bits sent from the key exchange protocol to the
   ESP algorithm must be greater than or equal to the key size.

   The cipher's encryption and decryption key is taken from the first
   128, 192, or 256 bits of the keying material.

4.2.  Counter with CBC MAC

   The ESP payload is composed of the IV followed by the ciphertext.
   The payload field, as defined in [ESP], is structured as shown in
   Figure 3.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Initialization Vector                     |
       |                            (8 octets)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                  Encrypted Payload (variable)                 ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                 Authentication Data (variable)                ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 3: ESP Payload Encrypted with Camellia-CCM

4.2.1.  Initialization Vector (IV)

   The Camellia-CCM IV field MUST be eight octets.  The IV MUST be
   chosen by the encryptor in a manner that ensures that the same IV
   value is used only once for a given key.  The encryptor can generate
   the IV in any manner that ensures uniqueness.  Common approaches to



Kato & Kanda              Expires May 16, 2007                 [Page 13]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   IV generation include incrementing a counter for each packet and
   linear feedback shift registers (LFSRs).

   Including the IV in each packet ensures that the decryptor can
   generate the key stream needed for decryption, even when some
   datagrams are lost or reordered.

4.2.2.  Encrypted Payload

   The encrypted payload contains the ciphertext.

   Camellia-CCM mode does not require plaintext padding.  However, ESP
   does require padding to 32-bit word-align the authentication data.
   The Padding, Pad Length, and Next Header fields MUST be concatenated
   with the plaintext before performing encryption, as described in
   [ESP].  When padding is required, it MUST be generated and checked in
   accordance with the conventions specified in [ESP].

4.2.3.  Authentication Data

   Camellia-CCM provides an encrypted ICV.  The ICV provided by CCM is
   carried in the Authentication Data fields without further encryption.
   Implementations MUST support ICV sizes of 8 octets and 16 octets.
   Implementations MAY also support ICV 12 octets.

4.2.4.  Nonce Format

   Each packet conveys the IV that is necessary to construct the
   sequence of counter blocks used by counter mode to generate the key
   stream.  The Camellia counter block is 16 octets.  One octet is used
   for the CCM Flags, and 4 octets are used for the block counter, as
   specified by the CCM L parameter.  The remaining octets are the
   nonce.  These octets occupy the second through the twelfth octets in
   the counter block.  Figure 4 shows the format of the nonce.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                  Salt                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Initialization Vector                     |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 4: Nonce Format of CCM

   The components of the nonce are as follows:



Kato & Kanda              Expires May 16, 2007                 [Page 14]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   Salt
      The salt field is 24 bits.  As the name implies, it contains an
      unpredictable value.  It MUST be assigned at the beginning of the
      security association.  The salt value need not be secret, but it
      MUST NOT be predictable prior to the beginning of the security
      association.

   Initialization Vector
      The IV field is 64 bits.  As described in Section 3.1, the IV MUST
      be chosen by the encryptor in a manner that ensures that the same
      IV value is used only once for a given key.

   This construction permits each packet to consist of up to:

            2^32 blocks  =  4,294,967,296 blocks
                         = 68,719,476,736 octets

   This construction provides more key stream for each packet than is
   needed to handle any IPv6 Jumbogram [JUMBO].

4.2.5.  AAD Construction

   The data integrity and data origin authentication for the Security
   Parameters Index (SPI) and (Extended) Sequence Number fields is
   provided without encrypting them.  Two formats are defined: one for
   32-bit sequence numbers and one for 64-bit extended sequence numbers.
   The format with 32-bit sequence numbers is shown in Figure 5, and the
   format with 64-bit extended sequence numbers is shown in Figure 6.

   Sequence Numbers are conveyed canonical network byte order.  Extended
   Sequence Numbers are conveyed canonical network byte order, placing
   the high-order 32 bits first and the low-order 32 bits second.
   Canonical network byte order is fully described in RFC 791, Appendix 
   B.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               SPI                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     32-bit Sequence Number                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 5:  AAD Format with 32-bit Sequence Number







Kato & Kanda              Expires May 16, 2007                 [Page 15]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               SPI                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 64-bit Extended Sequence Number               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 6:  AAD Format with 64-bit Sequence Number









































Kato & Kanda              Expires May 16, 2007                 [Page 16]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


5.  IKE Conventions

   Camellia was designed to follow the same API as the AES cipher.
   Therefore, this section defines only Phase 1 Identifier and Phase 2
   Identifier.  Any other consideration related to interaction with IKE
   is the same as that of the AES cipher.  Details can be found in IKE
   Conventions section of [AES-CTR] and [AES-CCM].

5.1.  Phase 1 Identifier

   This document does not specify the conventions for using Camellia-CTR
   and Camellia-CCM for IKE Phase 1 negotiations.  For Camellia-CTR and
   Camellia-CCM to be used in this manner, a separate specification is
   needed, and an Encryption Algorithm Identifier needs to be assigned.

5.2.  Phase 2 Identifier

   For IKE Phase 2 negotiations, IANA has assigned three ESP Transform
   Identifiers for Camellia-CTR and Camellia-CCM.

         <TBD> for Camellia-CTR with and explict IV;
         <TBD> for Camellia-CCM with an 8-octet ICV;
         <TBD> for Camellia-CCM with a 12-octet ICV; and
         <TBD> for Camellia-CCM with a 16-octet ICV.

5.3.  Key Length Attribute

   Since the Camellia supports three key lengths, the Key Length
   attribute MUST be specified in the IKE Phase 2 exchange [DOI].  The
   Key Length attribute MUST have a value of 128, 192, or 256.





















Kato & Kanda              Expires May 16, 2007                 [Page 17]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


6.  Security Considerations

   Camellia-CTR and Camellia-CCM employs counter (CTR) mode for
   confidentiality.  If a counter value is ever used for more that one
   packet with the same key, then the same key stream will be used to
   encrypt both packets, and the confidentiality guarantees are voided.

   What happens if the encryptor XORs the same key stream with two
   different packet plaintexts?  Suppose two packets are defined by two
   plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are
   encrypted with key stream K1, K2, K3.  The two corresponding
   ciphertexts are:

         (P1 XOR K1), (P2 XOR K2), (P3 XOR K3)

         (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)


   If both of these two ciphertext streams are exposed to an attacker,
   then a catastrophic failure of confidentiality results, because:

         (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
         (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
         (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3

   Once the attacker obtains the two plaintexts XORed together, it is
   relatively straightforward to separate them.  Thus, using any stream
   cipher, including Camellia-CTR, to encrypt two plaintexts under the
   same key stream leaks the plaintext.

   Therefore, Camellia-CTR and Camellia-CCM should not be used with
   statically configured keys.  Extraordinary measures would be needed
   to prevent the reuse of a counter block value with the static key
   across power cycles.  To be safe, implementations MUST use fresh keys
   with Camellia-CTR and Camellia-CCM.  The IKE [IKE] protocol can be
   used to establish fresh keys.

   When IKE is used to establish fresh keys between two peer entities,
   separate keys are established for the two traffic flows.  If a
   different mechanism is used to establish fresh keys, one that
   establishes only a single key to encrypt packets, then there is a
   high probability that the peers will select the same IV values for
   some packets.  Thus, to avoid counter block collisions, ESP
   implementations that permit use of the same key for encrypting and
   decrypting packets with the same peer MUST ensure that the two peers
   assign different salt values to the security association (SA).

   Regardless of the mode used, Camellia with a 128-bit key is



Kato & Kanda              Expires May 16, 2007                 [Page 18]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


   vulnerable to the birthday attack after 2^64 blocks are encrypted
   with a single key.  Since ESP with Extended Sequence Numbers allows
   for up to 2^64 packets in a single SA, there is real potential for
   more than 2^64 blocks to be encrypted with one key.  Implementations
   SHOULD generate a fresh key before 2^64 blocks are encrypted with the
   same key, or implementations SHOULD make use of the longer Camellia
   key sizes.  Note that ESP with 32-bit Sequence Numbers will not
   exceed 2^64 blocks even if all of the packets are maximum-length
   Jumbograms.










































Kato & Kanda              Expires May 16, 2007                 [Page 19]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


7.  IANA Considerations

   IANA has assigned three ESP transform numbers for use with Camellia-
   CTR and Camellia-CCM:

         <TBD> for Camellia-CTR with and explict IV;
         <TBD> for Camellia-CCM with an 8-octet ICV;
         <TBD> for Camellia-CCM with a 12-octet ICV; and
         <TBD> for Camellia-CCM with a 16-octet ICV.










































Kato & Kanda              Expires May 16, 2007                 [Page 20]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


8.  References

8.1.  Normative

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [Camellia-Desc]
              Matsui, M., Nakajima, J., and S. Moriai, "A Description of
              the Camellia Encryption Algorithm", RFC 3713, April 2004.

   [ESP]      Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

   [DOI]      Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMP", RFC 2407, November 1998.

   [CCM]      Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC(CCM)", RFC 3610, September 2003.

   [AES-CTR]  Housley, R., "Using Advanced Encryption Standard (AES)
              Counter Mode With IPsec Encapsulating Security Payload
              (ESP)", RFC 3686, January 2004.

   [AES-CCM]  Housley, R., "Using Advanced Encryption Standard (AES)
              Counter Mode With IPsec Encapsulating Security Payload
              (ESP)", RFC 4309, December 2005.

8.2.  Informative

   [Camellia-SMIME]
              Moriai, S. and A. Kato, "Use of the Camellia Encryption
              Algorithm in Cryptographic Message Syntax (CMS)",
              RFC 3657, January 2004.

   [Camellia-TLS]
              Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia
              Cipher Suites to Transport Layer Security (TLS)",
              RFC 4132, July 2005.

   [Camellia-IPsec]
              Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher
              Algorithm and Its Use With IPsec", RFC 4312,
              December 2005.

   [ISO/IEC 18033-3]
              International Organization for Standardization,
              "Information technology - Security techniques - Encryption



Kato & Kanda              Expires May 16, 2007                 [Page 21]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


              algorithms - Part 3: Block ciphers", ISO/IEC 18033-3,
              July 2005.

   [AES]      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>.

   [JUMBO]    Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, August 1999.

   [HMAC-SHA]
              Madson, C., Glenn, R., and P. Rogaway, "The Use of HMAC-
              SHA-196 within ESP and AH", RFC 2404, November 1998.

   [ARCH]     Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [CRYPTO-S]
              Schneier, B., "Applied Cryptography Second Edition",
              ISBN 0-471-12845-7, 1995.

   [CRYPTREC]
              Information-technology Promotion Agency (IPA),
              "Cryptography Research and Evaluation Committees",
              <http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html>.

   [IKE]      Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [IKEv2]    Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [MODES]    Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation - Methods and Techniques", NIST Special
              Publication 800-38A, November 2001, <http://csrc.nist.gov/
              publications/nistpubs/800-38a/sp800-38a.pdf>.

   [ROADMAP]  Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
              Document Roadmap", RFC 2411, November 1998.

   [NESSIE]   "The NESSIE project (New European Schemes for Signatures,
              Integrity and Encryption)",
              <http://www.cosic.esat.kuleuven.ac.be/nessie/>.







Kato & Kanda              Expires May 16, 2007                 [Page 22]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


URIs

   [1]  <http://info.isl.ntt.co.jp/camellia/>
















































Kato & Kanda              Expires May 16, 2007                 [Page 23]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


Authors' Addresses

   Akihiro Kato
   NTT Software Corporation

   Phone: +81-45-212-7094
   Fax:   +81-45-212-7506
   Email: akato@po.ntts.co.jp


   Masayuki Kanda
   Nippon Telegraph and Telephone Corporation

   Phone: +81-46-859-2437
   Fax:   +81-46-859-3365
   Email: kanda@isl.ntt.co.jp



































Kato & Kanda              Expires May 16, 2007                 [Page 24]

Internet-Draft  The Additional Modes of Camellia in IPsec  November 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Kato & Kanda              Expires May 16, 2007                 [Page 25]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/