RFC 5529

Modes of Operation for Camellia for Use with IPsec

📅 published April 2009, from ietf

RFC 5529: Modes of Operation for Camellia for Use with IPsec 🎀

Okay bestie, this one is by Akihiro Kato (NTT Software Corporation), Masayuki Kanda (NTT), and Satoru Kanno (NTT Software Corporation) 💖. It came out of the Network Working Group in April 2009 🌸. The category is Standards Track 🦋, and the header doesn't list anything it obsoletes or updates 🙈.

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it wants your thoughts and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 🧚.

Abstract 🌈

This document explains how to use the Camellia block cipher in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode. These are extra, optional-to-implement mechanisms for Internet Key Exchange Protocol version 2 (IKEv2) and Encapsulating Security Payload (ESP) 🔐. Together they give you confidentiality, data origin authentication, and connectionless integrity. Iconic 👑.

Table of Contents 🍓

1. Introduction ....................................................2
   1.1. Terminology ................................................3
2. The Camellia Cipher Algorithm ...................................3
   2.1. Block Size and Padding .....................................3
   2.2. Performance ................................................3
3. Modes ...........................................................3
   3.1. Cipher Block Chaining ......................................3
   3.2. Counter and Counter with CBC-MAC ...........................3
4. IKEv2 Conventions ...............................................4
   4.1. Keying Material ............................................4
   4.2. Transform Type 1 ...........................................5
   4.3. Key Length Attribute .......................................5
5. Security Considerations .........................................5
6. IANA Considerations .............................................5
7. Acknowledgments .................................................5
8. References ......................................................5
   8.1. Normative References .......................................5
   8.2. Informative References .....................................6

1. Introduction 💖

This document covers the Camellia block cipher [1] in CBC, CTR, and CCM modes. These are extra, optional-to-implement IKEv2 [2] and ESP [3] mechanisms that give you confidentiality, data origin authentication, and connectionless integrity ✨.

Camellia is already in several open source projects (OpenSSL, FreeBSD, Linux, and Firefox Gran Paradiso), and that's because the optimized source code is out under several open source licenses [9] 🌸.

The algorithm specification and object identifiers live in [1] 🧚.

The Camellia web site [10] is a whole treasure chest 💎. It has the detailed specification, security analysis, performance figures, a reference implementation, an optimized implementation, test vectors, and intellectual property information.

The rest of this document is about how to use the modes of operation for Camellia inside IPsec ESP 🦋. If you want the bigger picture of how IPsec and ESP work together to provide security services, check [11] and [3] 🫶.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4] 📖.

2. The Camellia Cipher Algorithm 🔑

All symmetric block cipher algorithms share the same basic traits and variables, like mode, key size, weak keys, block size, and rounds. The relevant Camellia characteristics are described in [1] 💅.

2.1. Block Size and Padding

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

Padding requirements are described as follows:

  • (a) Camellia Padding requirement is specified in [3],
  • (b) Camellia-CBC Padding requirement is specified in [3],
  • (c) Camellia-CCM Padding requirement is specified in [5], and
  • (d) ESP Padding requirement is specified in [3].

2.2. Performance ⚡

Performance figures for Camellia are at [10]. The NESSIE project also reported on the performance of optimized implementations, independently [12] 📊.

3. Modes 🎀

This document covers three modes of operation for using Camellia with IPsec: CBC (Cipher Block Chaining), CTR (Counter), and CCM (Counter with CBC-MAC) 💜.

3.1. Cipher Block Chaining

Camellia CBC mode is defined in [6] 🌷.

3.2. Counter and Counter with CBC-MAC

In IPsec, Camellia in CTR and CCM modes is used the same way AES is in [7] and [8]. In this spec, CCM is used with the Camellia [13] block cipher 🦄.

4. IKEv2 Conventions 🧚

This section covers the transform ID and the conventions for generating keying material for ENCR_CAMELLIA_CBC, ENCR_CAMELLIA_CTR, and ENCR_CAMELLIA_CCM, using IKEv2 [2] 💫.

4.1. Keying Material 🗝️

The size of KEYMAT MUST be equal to or longer than the associated Camellia key. Here's how the keying material gets used:

Camellia-CBC with a 128-bit key The KEYMAT requested for each Camellia-CBC key is 16 octets. All 16 octets are the 128-bit Camellia key.

Camellia-CBC with a 192-bit key The KEYMAT requested for each Camellia-CBC key is 24 octets. All 24 octets are the 192-bit Camellia key.

Camellia-CBC with a 256-bit key The KEYMAT requested for each Camellia-CBC key is 32 octets. All 32 octets are the 256-bit Camellia key.

Camellia-CTR with a 128-bit key The KEYMAT requested for each Camellia-CTR key is 20 octets. The first 16 octets are the 128-bit Camellia key, and the remaining four octets are used as the nonce value in the counter block.

Camellia-CTR with a 192-bit key The KEYMAT requested for each Camellia-CTR key is 28 octets. The first 24 octets are the 192-bit Camellia key, and the remaining four octets are used as the nonce value in the counter block.

Camellia-CTR with a 256-bit key The KEYMAT requested for each Camellia-CTR key is 36 octets. The first 32 octets are the 256-bit Camellia key, and the remaining four octets are used as the nonce value in the counter block.

Camellia-CCM with a 128-bit key The KEYMAT requested for each Camellia-CCM key is 19 octets. The first 16 octets are the 128-bit Camellia key, and the remaining three octets are used as the salt value in the counter block.

Camellia-CCM with a 192-bit key The KEYMAT requested for each Camellia-CCM key is 27 octets. The first 24 octets are the 192-bit Camellia key, and the remaining three octets are used as the salt value in the counter block.

Camellia-CCM with a 256-bit key The KEYMAT requested for each Camellia-CCM key is 35 octets. The first 32 octets are the 256-bit Camellia key, and the remaining three octets are used as the salt value in the counter block.

4.2. Transform Type 1 🪄

For IKEv2 negotiations, IANA has assigned five ESP Transform Identifiers for Camellia-CBC, Camellia-CTR, and Camellia-CCM, as recorded in Section 6 🎟️.

4.3. Key Length Attribute 📏

Camellia has three key lengths, so the Key Length attribute MUST be specified in the IKE exchange [2]. The Key Length attribute MUST have a value of 128, 192, or 256 bits 💯.

5. Security Considerations 🔒

Security is the whole vibe here, bestie 😭. For the security considerations of CTR and CCM mode, this document refers to Section 9 of [7] and Section 7 of [8]. Read those, no skipping!

No security problem has been found for Camellia [14], [12] 🛡️✨.

6. IANA Considerations 🏛️

IANA has assigned IKEv2 parameters for use with Camellia-CTR and with Camellia-CCM for Transform Type 1 (Encryption Algorithm):

      23 for ENCR_CAMELLIA_CBC;
      24 for ENCR_CAMELLIA_CTR;
      25 for ENCR_CAMELLIA_CCM with an 8-octet ICV;
      26 for ENCR_CAMELLIA_CCM with a 12-octet ICV; and
      27 for ENCR_CAMELLIA_CCM with a 16-octet ICV.

7. Acknowledgments 💌

Thank you to Tim Polk and Tero Kivinen for their initial review of this document 🫶. Thanks to Derek Atkins and Rui Hodai for their comments and suggestions 🌸. Special thanks to Alfred Hoenes, who gave several very detailed reviews and suggestions 👑.

8. References 📚

8.1. Normative References

  • [1] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004.
  • [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
  • [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [5] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality", NIST Special Publication 800-38C, July 2007, <http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C_updated-July20_2007.pdf>.
  • [6] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, December 2005.
  • [7] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
  • [8] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.

8.2. Informative References

Authors' Addresses 💖

  • Akihiro Kato, NTT Software Corporation. Phone: +81-45-212-7577, Fax: +81-45-212-9800, EMail: akato@po.ntts.co.jp
  • Masayuki Kanda, NTT. Phone: +81-422-59-3456, Fax: +81-422-59-4015, EMail: kanda.masayuki@lab.ntt.co.jp
  • Satoru Kanno, NTT Software Corporation. Phone: +81-45-212-7577, Fax: +81-45-212-9800, EMail: kanno-s@po.ntts.co.jp
📦 where this page comes from