Network Working Group A. Kato
Internet-Draft NTT Software Corporation
Updates: 4132 (if approved) M. Kanda
Intended status: Standards Track Nippon Telegraph and Telephone
Expires: January 8, 2009 Corporation
S. Kanno
NTT Software Corporation
July 7, 2008
Camellia Cipher Suites for TLS
draft-kato-tls-rfc4132bis-00
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 January 8, 2009.
Abstract
This document specifies set of cipher suites to the Transport Layer
Security (TLS) protocol to support the Camellia encryption algorithm
as a block cipher algorithm. This proposal provides options for fast
and efficient block cipher algorithms.
Kato, et al. Expires January 8, 2009 [Page 1]
Internet-Draft Camellia Cipher Suites for TLS July 2008
1. Introduction
This document proposes the addition of new cipher suites to the
Transport Layer Security (TLS) [RFC4346] protocol to support the
Camellia encryption algorithm as a block cipher algorithm.
Camellia is a symmetric cipher with a Feistel structure. Camellia
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)
[FIPS.197.2001].
Camellia supports 128-bit block size and 128-, 192-, and 256-bit key
lengths, i.e., the same interface specifications as the AES.
Therefore, it is easy to implement Camellia based algorithms by
replacing the AES block of AES based algorithms with a Camellia
block.
Camellia already has been adopted by the IETF and other international
standardization organizations; in particular, the IETF has published
specifications for the use of Camellia with IPsec [RFC4312], TLS
[RFC4132], S/MIME [RFC3657] and XML [RFC4051]. Camellia is one of
the three ISO/IEC international standard [ISO/IEC 18033-3] 128-bit
block ciphers (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 [NESSIE]
and was included in the list of cryptographic techniques for Japanese
e-Government systems that was selected by the Japanese CRYPTREC
(Cryptography Research and Evaluation Committees) [CRYPTREC].
Since optimized source code is provided under several open source
licenses [open source license], Camellia is also adopted by several
open source projects (OpenSSL, FreeBSD, and Linux). Camellia is also
adopted by Mozilla and Camellia is ready for use with Firefox 3.0
released in June 2008.
The algorithm specification and object identifiers are described in
[RFC3713]
The Camellia web site [Camellia web site] contains a wealth of
information about Camellia, including detailed specification,
security analysis, performance figures, reference implementation,
optimized implementation, test vectors(TV), and intellectual property
information.
Kato, et al. Expires January 8, 2009 [Page 2]
Internet-Draft Camellia Cipher Suites for TLS July 2008
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].
2. Proposed Cipher Suites
The cipher suites proposed here have the following definitions:
CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x41 };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x42 };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x43 };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x44 };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x45 };
CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x46 };
CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x84 };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x85 };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x86 };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x87 };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x88 };
CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x89 };
CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_anon_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_anon_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
3. Cipher Suite Definitions
3.1. Key Exchange
The cipher suites defined here differ in the type of certificate and
key exchange method. They use the following options:
Kato, et al. Expires January 8, 2009 [Page 3]
Internet-Draft Camellia Cipher Suites for TLS July 2008
Indicator of
Cipher Suite Key Exchange Algorithm
RSA RSA
DH_DSS DH_DSS
DH_RSA DH_RSA
DHE_DSS DHE_DSS
DHE_RSA DHE_RSA
DH_anon DH_anon
For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA,
and DH_anon, please refer to section 7.4.2. of [RFC4346].
3.2. Cipher
The cipher suites defined here and key sizes. They use the following
options:
Indicator of Key Expanded Effective IV Block
Cipher Suite Type Material Key Material Key Bits Size Size
CAMELLIA_128_CBC Block 16 16 128 16 16
CAMELLIA_256_CBC Block 32 32 256 16 16
3.3. MAC
The cipher suites defined here uses different type of hash functions
for calucuret MAC. They use the following options:
Indicator of
Cipher Suite MAC PRF
SHA HMAC-SHA-1 P_SHA-256
SHA256 HMAC-SHA-256 P_SHA-256
TLS1.1 or earlier versions uses SHA-1/MD5 combination for PRF. When
server and client select cipher suites indicated by SHA in TLS1.1 or
earlier versions, PRF MUST be calclated by TLS1.1 or earlier versions
manner.
Ciphersuite indicated by SHA256, SHA384 and SHA512 MUST NOT be
negotiated by TLS1.1 or earlier versions. Clients MUST NOT offer
cipher suites indicated by SHA256, SHA384 and SHA512 if they do not
offer TLS 1.2 or later. Servers which select an earlier version of
TLS MUST NOT select one of cipher suites indicated by SHA256, SHA384
and SHA512.
Because TLS has no way for the client to indicate that it supports
Kato, et al. Expires January 8, 2009 [Page 4]
Internet-Draft Camellia Cipher Suites for TLS July 2008
TLS 1.2 but not earlier, a non-compliant server might potentially
negotiate TLS 1.1 or earlier and select one of the cipher suites in
this document. Clients MUST check the TLS version and generate a
fatal "illegal_parameter" alert if they detect an incorrect version.
4. IANA Considerations
IANA has assigned the following values for these cipher suites:
CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x41 };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x42 };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x43 };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x44 };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x45 };
CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x46 };
CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x84 };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x85 };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x86 };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x87 };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x88 };
CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x89 };
CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_anon_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
CipherSuite TLS_DHE_anon_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD };
5. Security Considerations
At the time of writing this document, there are no known weak keys
for Camellia.
5.1. Downgrade Attack
TLS negotiation is only as secure as the weakest cipher suite that is
supported. For instance, an implementation which supports both 160-
Kato, et al. Expires January 8, 2009 [Page 5]
Internet-Draft Camellia Cipher Suites for TLS July 2008
bit and 256-bit elliptic curves can be subject to an active downgrade
attack to the 160-bit security level. An attacker who can attack
that can then forge the Finished handshake check and successfully
mount a man-in-the-middle attack.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia
Cipher Suites to Transport Layer Security (TLS)",
RFC 4132, July 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
6.2. Informative References
[CRYPTREC]
Information-technology Promotion Agency (IPA),
"Cryptography Research and Evaluation Committees",
<http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html>.
[Camellia web site]
"Camellia web site",
<http://info.isl.ntt.co.jp/camellia/>.
[FIPS.197.2001]
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>.
[ISO/IEC 18033-3]
International Organization for Standardization,
"Information technology - Security techniques - Encryption
algorithms - Part 3: Block ciphers", ISO/IEC 18033-3,
July 2005.
[NESSIE] "The NESSIE project (New European Schemes for Signatures,
Integrity and Encryption)",
<http://www.cosic.esat.kuleuven.ac.be/nessie/>.
[RFC3657] Moriai, S. and A. Kato, "Use of the Camellia Encryption
Kato, et al. Expires January 8, 2009 [Page 6]
Internet-Draft Camellia Cipher Suites for TLS July 2008
Algorithm in Cryptographic Message Syntax (CMS)",
RFC 3657, January 2004.
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of
the Camellia Encryption Algorithm", RFC 3713, April 2004.
[RFC4051] Eastlake, D., "Additional XML Security Uniform Resource
Identifiers (URIs)", RFC 4051, April 2005.
[RFC4312] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher
Algorithm and Its Use With IPsec", RFC 4312,
December 2005.
[open source license]
"Camellia open source software",
<http://info.isl.ntt.co.jp/crypt/eng/camellia/
source.html>.
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
Nippon Telegraph and Telephone Corporation
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
Kato, et al. Expires January 8, 2009 [Page 7]
Internet-Draft Camellia Cipher Suites for TLS July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Kato, et al. Expires January 8, 2009 [Page 8]