idnits 2.17.1 draft-kato-tls-rfc4132bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2010) is 5146 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-3' ** Downref: Normative reference to an Informational RFC: RFC 3713 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4132 (Obsoleted by RFC 5932) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kato 3 Internet-Draft NTT Software Corporation 4 Obsoletes: 4132 (if approved) M. Kanda 5 Intended status: Standards Track NTT 6 Expires: September 24, 2010 S. Kanno 7 NTT Software Corporation 8 March 23, 2010 10 Camellia Cipher Suites for TLS 11 draft-kato-tls-rfc4132bis-05 13 Abstract 15 This document specifies a set of cipher suites for the Transport 16 Security Layer (TLS) protocol to support the Camellia encryption 17 algorithm as a block cipher. It amends the cipher suites originally 18 specifed in RFC 4132 by counterparts using the newer cryptographic 19 hash algorithms from the SHA-2 familiy. This document obsoletes RFC 20 4132. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 24, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 1. Introduction 74 This document proposes the addition of new cipher suites to the 75 Transport Layer Security (TLS) [RFC5246] protocol to support the 76 Camellia [RFC3713] encryption algorithm as a block cipher algorithm, 77 adding variants using the SHA-2 family of cryptographic hash 78 algorithms [FIPS180-3] to the TLS cipher suite portfolio originally 79 specified in RFC 4132 [RFC4132]. This document obsoletes RFC 4132. 81 The Camellia algorithm and its properties are described in [RFC3713]. 83 1.1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Proposed Cipher Suites 91 The cipher suites defined here have the following identifiers: 93 CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x41 }; 94 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x42 }; 95 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x43 }; 96 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x44 }; 97 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x45 }; 98 CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x46 }; 100 CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x84 }; 101 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x85 }; 102 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x86 }; 103 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x87 }; 104 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x88 }; 105 CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x89 }; 107 CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 108 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 109 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 110 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 111 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 112 CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 114 CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 115 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 116 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 117 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 118 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 119 CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 121 3. Cipher Suite Definitions 123 3.1. Key Exchange 125 The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges 126 are performed as defined in [RFC5246]. 128 3.2. Cipher 130 The CAMELLIA_128_CBC cipher suites use Camellia [RFC3713] in CBC mode 131 with a 128-bit key and 128-bit IV; the CAMELLIA_256_CBC cipher suites 132 use a 256-bit key and 128-bit IV. 134 3.3. Hash and Pseudorandom Function 136 3.3.1. Hash and Pseudorandom Function for TLS 1.1 138 The cipher suites ending with _SHA use HMAC-SHA1 as the MAC 139 algorithm. 141 When used with TLS versions prior to 1.2, the PRF is calculated as 142 specified in the appropriate version of the TLS specification. 144 3.3.2. Hash and Pseudorandom Function for TLS 1.2 146 The cipher suites ending with _SHA256 use HMAC-SHA-256 as the MAC 147 algorithm. The PRF is the TLS PRF [RFC5246] with SHA-256 as the hash 148 function. These cipher suites MUST NOT be negotiated by TLS 1.1 or 149 earlier versions. Clients MUST NOT offer these cipher suites if they 150 do not offer TLS 1.2 or later. Servers which select an earlier 151 version of TLS MUST NOT select one of thse cipher suites. 153 4. IANA Considerations 155 IANA has already allocated the following numbers for RFC 4132, and is 156 requested to update them to reference this document: 158 CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x41 }; 159 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x42 }; 160 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x43 }; 161 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x44 }; 162 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x45 }; 163 CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x46 }; 165 CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x84 }; 166 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x85 }; 167 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x86 }; 168 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x87 }; 169 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x88 }; 170 CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x89 }; 172 IANA is requested to allocate (has allocated) the following numbers 173 in the TLS Cipher Suite Registry: 175 CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 176 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 177 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 178 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 179 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 180 CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 = { TBD,TBD }; 182 CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 183 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 184 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 185 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 186 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 187 CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 = { TBD,TBD }; 189 5. Security Considerations 191 At the time of writing this document there are no known weak keys for 192 Camellia. And no security problem has been found on Camellia (see 193 [NESSIE], [CRYPTREC], and [LNCS]). 195 Also, Security issues are discussed throughout RFC 5246 [RFC5246], 196 especially in Appendices D, E, and F of [RFC5246]. 198 6. References 200 6.1. Normative References 202 [FIPS180-3] 203 National Institute of Standards and Technology, "Secure 204 Hash Standard (SHS)", FIPS PUB 180, October 2008, . 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 212 the Camellia Encryption Algorithm", RFC 3713, April 2004. 214 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 215 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 217 6.2. Informative References 219 [CRYPTREC] 220 Information-technology Promotion Agency (IPA), 221 "Cryptography Research and Evaluation Committees", 222 . 224 [ISO/IEC 18033-3] 225 International Organization for Standardization, 226 "Information technology - Security techniques - Encryption 227 algorithms - Part 3: Block ciphers", ISO/IEC 18033-3, 228 July 2005. 230 [LNCS] Mala, H., Shakiba, M., and M. Dakhil-alian, "New Results 231 on Impossible Differential Cryptanalysis of Reduced Round 232 Camellia-128", November 2009, 233 . 235 [NESSIE] "The NESSIE project (New European Schemes for Signatures, 236 Integrity and Encryption)", 237 . 239 [RFC4132] Moriai, S., Kato, A., and M. Kanda, "Addition of Camellia 240 Cipher Suites to Transport Layer Security (TLS)", 241 RFC 4132, July 2005. 243 Authors' Addresses 245 Akihiro Kato 246 NTT Software Corporation 248 Phone: +81-45-212-9803 249 Fax: +81-45-212-9800 250 Email: kato.akihiro@po.ntts.co.jp 252 Masayuki Kanda 253 NTT 255 Phone: +81-422-59-3456 256 Fax: +81-422-59-4015 257 Email: kanda.masayuki@lab.ntt.co.jp 259 Satoru Kanno 260 NTT Software Corporation 262 Phone: +81-45-212-9803 263 Fax: +81-45-212-9800 264 Email: kanno.satoru@po.ntts.co.jp