idnits 2.17.1 draft-ietf-tls-camellia-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CamelliaSpec' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'CamelliaTech' is defined on line 226, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CamelliaSpec' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. 'AES-TLS') (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Moriai 3 TLS Working Group Sony Computer Entertainment Inc. 4 Expiration Date: August 2004 A. Kato 5 NTT Software Corporation 6 M. Kanda 7 Nippon Telegraph and Telephone Corporation 8 February 2004 10 Addition of Camellia Ciphersuites to Transport Layer Security (TLS) 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document proposes the addition of new cipher suites to the 38 Transport Layer Security (TLS) protocol to support the Camellia 39 encryption algorithm as a bulk cipher algorithm. 41 1. Introduction 43 This document proposes the addition of new cipher suites to the TLS 44 protocol [TLS] to support the Camellia encryption algorithm as a 45 bulk cipher algorithm. This proposal provides a new option for 46 fast, efficient, and royalty-free bulk cipher algorithms. 48 Note: This work was done when the first author worked for NTT. 50 1.1. Camellia 52 Camellia was selected as a recommended cryptographic primitive by 53 the EU NESSIE (New European Schemes for Signatures, Integrity and 54 Encryption) project [NESSIE] and included in the list of 55 cryptographic techniques for Japanese e-Government systems, which 56 were selected by the Japan CRYPTREC (Cryptography Research and 57 Evaluation Committees) [CRYPTREC]. Camellia is also included in 58 specification of the TV-Anytime Forum [TV-ANYTIME]. The TV-Anytime 59 Forum is an association of organizations that seeks to develop 60 specifications to enable audio-visual and other services based on 61 mass-market high volume digital storage in consumer 62 platforms. Camellia is specified as Ciphersuite in TLS used by Phase 63 1 S-7 (Bi-directional Metadata Delivery Protection) 64 specification. Camellia has been submitted to other several 65 standardization bodies such as ISO (ISO/IEC 18033) and IETF S/MIME 66 Mail Security Working Group [Camellia-CMS]. 68 Camellia supports 128-bit block size and 128-, 192-, and 256-bit key 69 sizes, i.e. the same interface specifications as the Advanced 70 Encryption Standard (AES) [AES]. 72 Camellia was jointly developed by NTT and Mitsubishi Electric 73 Corporation in 2000. It was carefully designed to withstand all 74 known cryptanalytic attacks and even to have a sufficiently large 75 security leeway. It has been scrutinized by worldwide 76 cryptographic experts. 78 Camellia was also designed to have suitability for both software 79 and hardware implementations and to cover all possible encryption 80 applications that range from low-cost smart cards to high-speed 81 network systems. Compared to the AES, Camellia offers at least 82 comparable encryption speed in software and hardware. In 83 addition, a distinguishing feature is its small hardware design. 84 Camellia perfectly meets one of the current TLS market 85 requirements, where low power consumption is a mandatory 86 condition. 88 The Camellia homepage, http://info.isl.ntt.co.jp/camellia/, 89 contains a wealth of information about camellia, including 90 detailed specification, security analysis, performance figures, 91 reference implementation, test vectors, and intellectual property 92 information. 94 1.2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 97 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 98 as shown) are to be interpreted as described in [RFC2119]. 100 2. Proposed Cipher Suites 102 The new ciphersuites proposed here have the following definitions: 104 CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x41 }; 105 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x42 }; 106 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x43 }; 107 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x44 }; 108 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x45 }; 109 CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x46 }; 111 CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x84 }; 112 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x85 }; 113 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x86 }; 114 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x87 }; 115 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x88 }; 116 CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x89 }; 118 3. CipherSuite Definitions 120 3.1. Cipher 122 All the ciphersuites described here use Camellia in cipher block 123 chaining (CBC) mode as a bulk cipher algorithm. Camellia is a 124 128-bit block cipher with 128-, 192-, and 256-bit key sizes, i.e. it 125 supports the same block and key sizes as the Advanced Encryption 126 Standard (AES). However, this document only defines ciphersuites 127 for 128- and 256-bit keys as well as AES ciphersuites for TLS 128 [AES-TLS]. They are enough for use in efficient and practical cases 129 as well as high-security applications. 131 Key Expanded Effective IV Block 132 Cipher Type Material Key Material Key Bits Size Size 134 CAMELLIA_128_CBC Block 16 16 128 16 16 135 CAMELLIA_256_CBC Block 32 32 256 16 16 137 3.2. Hash 139 All the ciphersuites described here use SHA-1 [SHA-1] in an HMAC 140 construction as described in section 5 of [TLS]. 142 3.3. Key exchange 144 The ciphersuites defined here differ in the type of certificate and 145 key exchange method. They use the following options: 147 CipherSuite Key Exchange Algorithm 149 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA RSA 150 TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA DH_DSS 151 TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA DH_RSA 152 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE_DSS 153 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE_RSA 154 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA DH_anon 156 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA RSA 157 TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA DH_DSS 158 TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA DH_RSA 159 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE_DSS 160 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE_RSA 161 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA DH_anon 163 For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA 164 and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS]. 166 4. Security Considerations 168 It is not believed that the new ciphersuites are ever less secure 169 than the corresponding older ones. Camellia is considered to be 170 secure, and it has withstood extensive cryptanalytic efforts in 171 several open, worldwide cryptographic evaluation projects 172 [CRYPTREC][NESSIE]. 174 At the time of writing this document there are no known weak keys 175 for Camellia. 177 For other security considerations, please refer to the security 178 considerations of the corresponding older ciphersuites described 179 in [TLS] and [AES-TLS]. 181 5. Intellectual Property Rights 183 The IETF takes no position regarding the validity or scope of any 184 intellectual property or other rights that might be claimed to 185 pertain to the implementation or use of the technology described 186 in this document or the extent to which any license under such 187 rights might or might not be available; neither does it represent 188 that it has made any effort to identify any such rights. 189 Information on the IETF's procedures with respect to rights in 190 standards-track and standards-related documentation can be found 191 in BCP-11. Copies of claims of rights made available for 192 publication and any assurances of licenses to be made available, 193 or the result of an attempt made to obtain a general license or 194 permission for the use of such proprietary rights by implementors 195 or users of this specification can be obtained from the IETF 196 Secretariat. 198 The IETF invites any interested party to bring to its attention 199 any copyrights, patents or patent applications, or other 200 proprietary rights which may cover technology that may be required 201 to practice this standard. Please address the information to the 202 IETF Executive Director. 204 The IETF has been notified of intellectual property rights 205 claimed in regard to some or all of the specification contained in 206 this document. For more information consult the online list of 207 claimed rights. 209 6. References 211 6.1. Normative References 213 [CamelliaSpec] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 214 J. Nakajima, and T. Tokita, "Specification of Camellia - a 128-bit 215 Block Cipher". 216 http://info.isl.ntt.co.jp/camellia/CRYPTREC/2001/01espec.pdf. 218 [TLS] T. Dierks, and C. Allen, "The TLS Protocol Version 1.0", RFC 219 2246, January 1999. 221 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 6.2. Informative References 226 [CamelliaTech] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 227 J. Nakajima, and T. Tokita, "Camellia: A 128-Bit Block Cipher 228 Suitable for Multiple Platforms - Design and Analysis -", In 229 Selected Areas in Cryptography, 7th Annual International 230 Workshop, SAC 2000, August 2000, Proceedings, Lecture Notes in 231 Computer Science 2012, pp.39-56, Springer-Verlag, 2001. 233 [Camellia-CMS] S. Moriai and A. Kato, "Use of the Camellia 234 Encryption Algorithm in Cryptographic Message Syntax (CMS)", 235 RFC 3657, January 2004. 237 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", 238 November 2001. http://csrc.nist.gov/publications/fips/fips197/ 239 fips-197.{ps,pdf}. 241 [AES-TLS] P. Chown, "Advanced Encryption Standard (AES) 242 Ciphersuites for Transport Layer Security (TLS)", RFC 3268, 243 June 2002. 245 [SHA-1] FIPS PUB 180-1, "Secure Hash Standard", National Institute 246 of Standards and Technology, U.S. Department of Commerce,April 17, 247 1995. 249 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 250 CRYPTREC. http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html. 252 [NESSIE] The NESSIE project (New European Schemes for Signatures, 253 Integrity and Encryption), 254 http://www.cosic.esat.kuleuven.ac.be/nessie/. 256 [TV-ANYTIME] TV-Anytime Forum, http://www.tv-anytime.org/. 258 Authors' Addresses 260 Shiho Moriai 261 Sony Computer Entertainment Inc. 262 Phone: +81-3-6438-7523 263 Fax: +81-3-6438-8629 264 Email: camellia@isl.ntt.co.jp (Camellia team) 265 shiho@rd.scei.sony.co.jp (Shiho Moriai) 267 Akihiro Kato 268 NTT Software Corporation 269 Phone: +81-45-212-7934 270 Fax: +81-45-212-9800 271 Email: akato@po.ntts.co.jp 273 Masayuki Kanda 274 Nippon Telegraph and Telephone Corporation 275 Phone: +81-46-859-2437 276 FAX: +81-46-859-3365 277 Email: kanda@isl.ntt.co.jp