TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 March 13, 2010.
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 review these documents carefully, as they describe your rights and restrictions with respect to this document.
This memo specifies two new algorithms. One is the usage of XCBC mode with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-XCBC-96. Latter is pseudo-random function based on XCBC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF-128.
1.
Introduction
1.1.
Terminology
2.
Camellia-XCBC-96 and Camellia-XCBC-PRF-128
3.
Test Vectors
3.1.
Camellia-XCBC-96
3.2.
Camellia-XCBC-PRF-128
4.
Security Considerations
5.
IANA Considerations
6.
Acknowledgements
7.
References
7.1.
Normative
7.2.
Informative
§
Authors' Addresses
TOC |
This document specifies two new algorithms. One is the usage of XCBC based on Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload (ESP) [7] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) and Authentication Header protocols (AH) [6] (Kent, S., “IP Authentication Header,” December 2005.). This algorithm is called Camellia-XCBC-96. Latter is Pseudo-Random Function (PRF) based on XCBC with Camellia block cipher for Internet Key Exchange (IKEv2) [8] (Kaufman, C., Hoffman, P., and P. Eronen, “Internet Key Exchange Protocol: IKEv2,” February 2008.). This algorithm is called Camellia-XCBC-PRF-128.
The Camellia algorithm specification and object identifiers are described in [2] (Matsui, M., Nakajima, J., and S. Moriai, “A Description of the Camellia Encryption Algorithm,” April 2004.).
TOC |
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 [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
TOC |
The Camellia-XCBC-96 comply with [3] (Frankel, S. and H. Herbert, “The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec,” September 2003.). Also, The Camellia-XCBC-PRF-128 comply with [4] (Hoffman, P., “The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE),” February 2006.).
TOC |
TOC |
This section contains three test vectors(TV), which can be used to confirm that an implementation has correctly implemented Camellia-XCBC-96.
Test Case #1 : Camellia-XCBC-MAC-96 with 20-byte input Key (K) : 000102030405060708090a0b0c0d0e0f Message (M) : 000102030405060708090a0b0c0d0e0f10111213 Camellia-XCBC-MAC : 3d042dd4e7bc791cee320415c5e326d6 Camellia-XCBC-MAC-96: 3d042dd4e7bc791cee320415 Test Case #2 : Camellia-XCBC-MAC-96 with 20-byte input Key (K) : 00010203040506070809 Message (M) : 000102030405060708090a0b0c0d0e0f10111213 Camellia-XCBC-MAC : b916b423420a906cd7d7b672a24e976f Camellia-XCBC-MAC-96: b916b423420a906cd7d7b672 Test Case #3 : Camellia-XCBC-MAC-96 with 20-byte input Key (K) : 000102030405060708090a0b0c0d0e0fedcb Message (M) : 000102030405060708090a0b0c0d0e0f10111213 Camellia-XCBC-MAC : b97146369d31940ff57a0ddf2233c1d2 Camellia-XCBC-MAC-96: b97146369d31940ff57a0ddf
TOC |
This section contains three test vectors(TV), which can be used to confirm that an implementation has correctly implemented Camellia-XCBC-PRF-128.
Test Case #1 : Camellia-XCBC-PRF-128 with 20-byte input Key : 000102030405060708090a0b0c0d0e0f Key Length : 16 Message : 000102030405060708090a0b0c0d0e0f10111213 PRF Output : fb8f550070b5e6a51aa2404ff8bbcf7d3d042dd4e7bc791cee320415c5e326d6 Test Case #2 : Camellia-XCBC-PRF-128 with 20-byte input Key : 00010203040506070809 Key Length : 10 Message : 000102030405060708090a0b0c0d0e0f10111213 PRF Output : e8243b0105b3a3b93fd6cedae0ca8ab6b916b423420a906cd7d7b672a24e976f Test Case #3 : Camellia-XCBC-PRF-128 with 20-byte input Key : 000102030405060708090a0b0c0d0e0fedcb Key Length : 18 Message : 000102030405060708090a0b0c0d0e0f10111213 PRF Output : bd75834d3452f9087d1597a87a33bc33b97146369d31940ff57a0ddf2233c1d2
TOC |
At the time of writing this document there are no known weak keys for Camellia. And no security problem has been found on Camellia [10] (, “The NESSIE project (New European Schemes for Signatures, Integrity and Encryption),” .), [11] (Information-technology Promotion Agency (IPA), “Cryptography Research and Evaluation Committees,” .)
For other security considerations, please refer to the security considerations of the previous use of XCBC mode document described in [3] (Frankel, S. and H. Herbert, “The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec,” September 2003.) and [4] (Hoffman, P., “The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE),” February 2006.).
TOC |
IANA has assigned AH/ESP Authentication Algorithm Value <TBD2> for IKEv2 Transform Type 3 (Integrity Algorithm) to CAMELLIA-XCBC-MAC. IANA has assigned AH Transform Identifier <TBD1> for IKEv2 Transform Type 2 (Pseudo-Random Function) to AH_CAMELLIA-XCBC-MAC.
TOC |
This document unabashedly referred to [3] (Frankel, S. and H. Herbert, “The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec,” September 2003.) and [4] (Hoffman, P., “The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE),” February 2006.).
TOC |
TOC |
[1] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[2] | Matsui, M., Nakajima, J., and S. Moriai, “A Description of the Camellia Encryption Algorithm,” RFC 3713, April 2004 (TXT). |
[3] | Frankel, S. and H. Herbert, “The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec,” RFC 3566, September 2003 (TXT). |
[4] | Hoffman, P., “The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE),” RFC 4434, February 2006 (TXT). |
[5] | Black, J. and P. Rogaway, “Fast Encryption and Authentication: XCBC Encryption and XECB Authentication Modes,” August 2001. |
TOC |
[6] | Kent, S., “IP Authentication Header,” RFC 4302, December 2005 (TXT). |
[7] | Kent, S., “IP Encapsulating Security Payload (ESP),” RFC 4303, December 2005 (TXT). |
[8] | Kaufman, C., Hoffman, P., and P. Eronen, “Internet Key Exchange Protocol: IKEv2,” draft-hoffman-ikev2bis-03 (work in progress), February 2008 (TXT). |
[9] | Kato, A., Moriai, S., and M. Kanda, “The Camellia Cipher Algorithm and Its Use With IPsec,” RFC 4312, December 2005 (TXT). |
[10] | “The NESSIE project (New European Schemes for Signatures, Integrity and Encryption).” |
[11] | Information-technology Promotion Agency (IPA), “Cryptography Research and Evaluation Committees” (HTML). |
TOC |
Satoru Kanno | |
NTT Software Corporation | |
Phone: | +81-45-212-7577 |
Fax: | +81-45-212-9800 |
Email: | kanno.satoru@po.ntts.co.jp |
Akihiro Kato | |
NTT Software Corporation | |
Phone: | +81-45-212-7577 |
Fax: | +81-45-212-9800 |
Email: | kato.akihiro@po.ntts.co.jp |
Masayuki Kanda | |
NTT | |
Phone: | +81-422-59-3456 |
Fax: | +81-422-59-4015 |
Email: | kanda.masayuki@lab.ntt.co.jp |