idnits 2.17.1 draft-ietf-tls-camellia-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 211. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (October 2004) is 7132 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: 'CamelliaTech' is defined on line 229, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3713 (ref. 'Camellia-Desc') ** 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: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 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: March 2005 A. Kato 5 NTT Software Corporation 6 M. Kanda 7 Nippon Telegraph and Telephone Corporation 8 October 2004 10 Addition of Camellia Ciphersuites to Transport Layer Security (TLS) 12 14 Status of this Memo 16 By submitting this Internet-Draft, we certify that any applicable 17 patent or other IPR claims of which we am aware have been 18 disclosed, and any of which we become aware will be disclosed, in 19 accordance with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document proposes the addition of new cipher suites to the 41 Transport Layer Security (TLS) protocol to support the Camellia 42 encryption algorithm as a bulk cipher algorithm. 44 1. Introduction 46 This document proposes the addition of new cipher suites to the 47 TLS protocol [TLS] to support the Camellia encryption algorithm as 48 a bulk cipher algorithm. This proposal provides a new option for 49 fast and efficient bulk cipher algorithms. 51 Note: This work was done when the first author worked for NTT. 53 1.1. Camellia 55 Camellia was selected as a recommended cryptographic primitive by 56 the EU NESSIE (New European Schemes for Signatures, Integrity and 57 Encryption) project [NESSIE] and included in the list of 58 cryptographic techniques for Japanese e-Government systems, which 59 were selected by the Japan CRYPTREC (Cryptography Research and 60 Evaluation Committees) [CRYPTREC]. Camellia is also included in 61 specification of the TV-Anytime Forum [TV-ANYTIME]. The TV-Anytime 62 Forum is an association of organizations that seeks to develop 63 specifications to enable audio-visual and other services based on 64 mass-market high volume digital storage in consumer 65 platforms. Camellia is specified as Ciphersuite in TLS used by 66 Phase 1 S-7 (Bi-directional Metadata Delivery Protection) 67 specification and S-5 (TV-Anytime Rights Management and Protection 68 Information for Broadcast Applications) specification. Camellia 69 has been submitted to other several standardization bodies such as 70 ISO (ISO/IEC 18033) and IETF S/MIME Mail Security Working Group 71 [Camellia-CMS]. 73 Camellia supports 128-bit block size and 128-, 192-, and 256-bit 74 key sizes, i.e. the same interface specifications as the Advanced 75 Encryption Standard (AES) [AES]. 77 Camellia was jointly developed by NTT and Mitsubishi Electric 78 Corporation in 2000. It was carefully designed to withstand all 79 known cryptanalytic attacks and even to have a sufficiently large 80 security leeway. It has been scrutinized by worldwide 81 cryptographic experts. 83 Camellia was also designed to have suitability for both software 84 and hardware implementations and to cover all possible encryption 85 applications that range from low-cost smart cards to high-speed 86 network systems. Compared to the AES, Camellia offers at least 87 comparable encryption speed in software and hardware. In 88 addition, a distinguishing feature is its small hardware design. 89 Camellia perfectly meets one of the current TLS market 90 requirements, where low power consumption is a mandatory 91 condition. 93 The algorithm specification and object identifiers are described 94 in [Camellia-Desc]. The Camellia homepage, 95 http://info.isl.ntt.co.jp/camellia/, contains a wealth of 96 information about camellia, including detailed specification, 97 security analysis, performance figures, reference implementation 98 and test vectors. 100 1.2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 103 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 104 uppercase, as shown) are to be interpreted as described in 105 [RFC2119]. 107 2. Proposed Cipher Suites 109 The new ciphersuites proposed here have the following definitions: 111 CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x41 }; 112 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x42 }; 113 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x43 }; 114 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x44 }; 115 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x45 }; 116 CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x46 }; 118 CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x84 }; 119 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x85 }; 120 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x86 }; 121 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x87 }; 122 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x88 }; 123 CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x89 }; 125 3. CipherSuite Definitions 127 3.1. Cipher 129 All the ciphersuites described here use Camellia in cipher block 130 chaining (CBC) mode as a bulk cipher algorithm. Camellia is a 131 128-bit block cipher with 128-, 192-, and 256-bit key sizes, 132 i.e. it supports the same block and key sizes as the Advanced 133 Encryption Standard (AES). However, this document only defines 134 ciphersuites for 128- and 256-bit keys as well as AES ciphersuites 135 for TLS [AES-TLS]. They are enough for use in efficient and 136 practical cases as well as high-security applications. 138 Key Expanded Effective IV Block 139 Cipher Type Material Key Material Key Bits Size Size 141 CAMELLIA_128_CBC Block 16 16 128 16 16 142 CAMELLIA_256_CBC Block 32 32 256 16 16 144 3.2. Hash 146 All the ciphersuites described here use SHA-1 [SHA-1] in an HMAC 147 construction as described in section 5 of [TLS]. 149 3.3. Key exchange 151 The ciphersuites defined here differ in the type of certificate 152 and key exchange method. They use the following options: 154 CipherSuite Key Exchange Algorithm 156 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA RSA 157 TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA DH_DSS 158 TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA DH_RSA 159 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE_DSS 160 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE_RSA 161 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA DH_anon 163 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA RSA 164 TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA DH_DSS 165 TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA DH_RSA 166 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE_DSS 167 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE_RSA 168 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA DH_anon 170 For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, 171 DHE_RSA and DH_anon, please refer to sections 7.4.2 and 7.4.3 of 172 [TLS]. 174 4. Security Considerations 176 It is not believed that the new ciphersuites are ever less secure 177 than the corresponding older ones. Camellia is considered to be 178 secure, and it has withstood extensive cryptanalytic efforts in 179 several open, worldwide cryptographic evaluation projects 180 [CRYPTREC][NESSIE]. 182 At the time of writing this document there are no known weak keys 183 for Camellia. 185 For other security considerations, please refer to the security 186 considerations of the corresponding older ciphersuites described 187 in [TLS] and [AES-TLS]. 189 5. Intellectual Property Rights 191 The IETF takes no position regarding the validity or scope of any 192 Intellectual Property Rights or other rights that might be claimed 193 to pertain to the implementation or use of the technology 194 described in this document or the extent to which any license 195 under such rights might or might not be available; nor does it 196 represent that it has made any independent effort to identify any 197 such rights. Information on the procedures with respect to rights 198 in RFC documents can be found in BCP 78 and BCP 79. 200 Copies of IPR disclosures made to the IETF Secretariat and any 201 assurances of licenses to be made available, or the result of an 202 attempt made to obtain a general license or permission for the use 203 of such proprietary rights by implementers or users of this 204 specification can be obtained from the IETF on-line IPR repository 205 at http://www.ietf.org/ipr. 207 The IETF invites any interested party to bring to its attention 208 any copyrights, patents or patent applications, or other 209 proprietary rights that may cover technology that may be required 210 to implement this standard. Please address the information to the 211 IETF at ietf-ipr@ietf.org. 213 6. References 215 6.1. Normative References 217 [Camellia-Desc] Matsui, M., Nakajima, J., Moriai, S., "A 218 Description of the Camellia Encryption Algorithm", RFC3713, 219 April 2004. 221 [TLS] Dierks, T. and Allen, C. "The TLS Protocol Version 1.0", 222 RFC 2246, January 1999. 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 6.2. Informative References 229 [CamelliaTech] Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., 230 Moriai, S., Nakajima, J., and Tokita, T., "Camellia: A 128-Bit 231 Block Cipher Suitable for Multiple Platforms - Design and 232 Analysis -", In Selected Areas in Cryptography, 7th Annual 233 International Workshop, SAC 2000, August 2000, Proceedings, 234 Lecture Notes in Computer Science 2012, pp.39-56, 235 Springer-Verlag, 2001. 237 [Camellia-CMS] Moriai, S. and Kato, A., "Use of the Camellia 238 Encryption Algorithm in CMS", January 2004, RFC3657. 240 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", 241 November 2001. http://csrc.nist.gov/publications/fips/fips197/ 242 fips-197.{ps,pdf}. 244 [AES-TLS] Chown, P., "Advanced Encryption Standard (AES) 245 Ciphersuites for Transport Layer Security (TLS)", RFC 3268, 246 June 2002. 248 [SHA-1] FIPS PUB 180-1, "Secure Hash Standard", National Institute 249 of Standards and Technology, U.S. Department of Commerce,April 250 17, 1995. 252 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 253 CRYPTREC. 254 http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html. 256 [NESSIE] The NESSIE project (New European Schemes for Signatures, 257 Integrity and Encryption), 258 http://www.cosic.esat.kuleuven.ac.be/nessie/. 260 [TV-ANYTIME] TV-Anytime Forum, http://www.tv-anytime.org/. 262 7. Full Copyright Statement 264 Copyright (C) The Internet Society (2004). This document is 265 subject to the rights, licenses and restrictions contained in BCP 266 78 and except as set forth therein, the authors retain all their 267 rights. 269 This document and the information contained herein are provided on 270 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 271 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 272 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 273 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 274 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 275 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 276 PARTICULAR PURPOSE. 278 Authors' Addresses 280 Shiho Moriai 281 Sony Computer Entertainment Inc. 282 Phone: +81-3-6438-7523 283 Fax: +81-3-6438-8629 284 Email: camellia@isl.ntt.co.jp (Camellia team) 285 shiho "at" rd.scei.sony.co.jp (Shiho Moriai) 287 Akihiro Kato 288 NTT Software Corporation 289 Phone: +81-45-212-7934 290 Fax: +81-45-212-9800 291 Email: akato@po.ntts.co.jp 293 Masayuki Kanda 294 Nippon Telegraph and Telephone Corporation 295 Phone: +81-46-859-2437 296 FAX: +81-46-859-3365 297 Email: kanda@isl.ntt.co.jp