idnits 2.17.1 draft-krb-wg-kanno-camellia-01.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 date (February 25, 2010) is 5166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kanno 3 Internet-Draft NTT Software Corporation 4 Intended status: Informational K. Raeburn 5 Expires: August 29, 2010 Massachusetts Institute of 6 Technology 7 M. Kanda 8 NTT 9 T. Hardjono 10 Massachusetts Institute of 11 Technology 12 February 25, 2010 14 Camellia Encryption for Kerberos 5 15 draft-krb-wg-kanno-camellia-01 17 Abstract 19 This document is a specification for the addition of Camellia cipher 20 to the Kerberos 5 cryptosystem suite. The Camellia cipher was 21 developed by NTT and Mitsubishi Electric Corporation in 2000, which 22 is comparable to Advanced Encryption Standard (AES). 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 29, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 1. Introduction 63 This document defines encryption key and checksum types for Kerberos 64 5 using the Camellia algorithm developed by NTT and Mitsubishi 65 Electric Corporation in 2000. These new types support 128-bit block 66 encryption and key sizes of 128 or 256 bits. It is same that 67 interface speficiations as the AES. 69 The Camellia algorithm and its properties are described in [RFC3713]. 71 Using the "simplified profile" of [RFC3961], we can define a pair of 72 encryption and checksum schemes. Camellia is used with ciphertext 73 stealing (CTS) to avoid message expansion, and SHA-1 is the 74 associated checksum function. 76 2. Terminology 78 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 80 appear in this document are to be interpreted as described in 81 [RFC2119]. 83 3. Protocol Key Representation 85 The profile in [RFC3961] treats keys and random octet strings as 86 conceptually different. But since the AES key space is dense, we can 87 use any bit string of appropriate length as a key. We use the byte 88 representation for the key described in [RFC3713], where the first 89 bit of the bit string is the high bit of the first byte of the byte 90 string (octet string) representation. 92 4. Key Generation from Pass Phrases or Random Data 94 Given the above format for keys, we can generate keys from the 95 appropriate amounts of random data (128 or 256 bits) by simply 96 copying the input string. 98 To generate an encryption key from a pass phrase and salt string, the 99 Camellia uses the PBKDF2 function from PKCS #5 v2.0 [RFC2898]. This 100 function of Camellia can define as same specification of AES 101 [RFC3962] 103 The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the 104 passphrase and salt. The case of AES described in Appendix B of 105 [RFC3962]. For pseudorandom function, Camellia can use like an AES. 107 5. CipherText Stealing mode 109 The specification of CipherText Stealing (CTS) mode for Camellia 110 complies with AES-CTS in [RFC3962]. 112 A test vector of Camellia-CTS is given in Section 10. 114 6. Kerberos Algorithm Profile Parameters 116 This is a summary of the parameters to be used with the simplified 117 algorithm profile described in [RFC3961]: 119 +--------------------------------------------------------------------+ 120 | protocol key format 128- or 256-bit string | 121 | | 122 | string-to-key function PBKDF2+DK with variable | 123 | iteration count | 124 | | 125 | default string-to-key parameters 00 00 10 00 | 126 | | 127 | key-generation seed length key size | 128 | | 129 | random-to-key function identity function | 130 | | 131 | hash function, H SHA-1 | 132 | | 133 | HMAC output size, h 12 octets (96 bits) | 134 | | 135 | message block size, m 1 octet | 136 | | 137 | encryption/decryption functions, Camellia in CBC-CTS mode | 138 | E and D (cipher block size 16 | 139 | octets), with next-to- | 140 | last block (last block | 141 | if only one) as CBC-style | 142 | ivec | 143 +--------------------------------------------------------------------+ 145 Using this profile with each key size gives us two each of encryption 146 and checksum algorithm definitions. 148 7. Assigned Numbers 150 The following encryption type numbers are assigned: 152 +--------------------------------------------------------------------+ 153 | encryption types | 154 +--------------------------------------------------------------------+ 155 | type name etype value key size | 156 +--------------------------------------------------------------------+ 157 | camellia128-cts-hmac-sha1-96 128 | 158 | camellia256-cts-hmac-sha1-96 256 | 159 +--------------------------------------------------------------------+ 161 The following checksum type numbers are assigned: 163 +--------------------------------------------------------------------+ 164 | checksum types | 165 +--------------------------------------------------------------------+ 166 | type name sumtype value length | 167 +--------------------------------------------------------------------+ 168 | hmac-sha1-96-camellia128 96 | 169 | hmac-sha1-96-camellia256 96 | 170 +--------------------------------------------------------------------+ 172 These checksum types will be used with the corresponding encryption 173 types defined above. 175 8. Security Considerations 177 At the time of writing this document there are no known weak keys for 178 Camellia. And no security problem has been found on Camellia (see 179 [NESSIE], [CRYPTREC], and [LNCS]). 181 For security considerations of CTS mode, this document refers to 182 Section 8 of [RFC3962]. 184 9. IANA Considerations 186 Kerberos encryption and checksum type values used in section 7 were 187 previously reserved in [RFC3961] for the mechanisms defined in this 188 document. The registries have been updated to list this document as 189 the reference. 191 10. Test Vector 193 Some test vectors for CTS mode, using an initial vector of all-zero. 195 Camellia 128-bit key: 196 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69 198 IV: 199 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 200 Input: 201 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 202 0010: 20 203 Output: 204 0000: 205 0010: 206 Next IV: 207 0000: 209 IV: 210 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 211 Input: 212 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 213 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 214 Output: 215 0000: 216 0010: 217 Next IV: 218 0000: 220 IV: 221 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 222 Input: 223 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 224 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 225 Output: 226 0000: 227 0010: 228 Next IV: 229 0000: 231 IV: 232 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 233 Input: 234 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 235 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 236 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 237 Output: 238 0000: 239 0010: 240 0020: 241 Next IV: 242 0000: 244 IV: 245 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 246 Input: 247 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 248 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 249 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 250 Output: 251 0000: 252 0010: 253 0020: 254 Next IV: 255 0000: 257 IV: 258 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 259 Input: 260 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 261 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 262 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 263 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e 264 Output: 265 0000: 266 0010: 267 0020: 268 0030: 269 Next IV: 270 0000: 272 11. References 274 11.1. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 280 Specification Version 2.0", RFC 2898, September 2000. 282 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 283 the Camellia Encryption Algorithm", RFC 3713, April 2004. 285 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 286 Kerberos 5", RFC 3961, February 2005. 288 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 289 Encryption for Kerberos 5", RFC 3962, February 2005. 291 11.2. Informative References 293 [CRYPTREC] 294 Information-technology Promotion Agency (IPA), 295 "Cryptography Research and Evaluation Committees", 296 . 298 [ISO/IEC 18033-3] 299 International Organization for Standardization, 300 "Information technology - Security techniques - Encryption 301 algorithms - Part 3: Block ciphers", ISO/IEC 18033-3, 302 July 2005. 304 [LNCS] Mala, H., Shakiba, M., and M. Dakhil-alian, "New Results 305 on Impossible Differential Cryptanalysis of Reduced Round 306 Camellia-128", November 2009, 307 . 309 [NESSIE] "The NESSIE project (New European Schemes for Signatures, 310 Integrity and Encryption)", 311 . 313 Authors' Addresses 315 Satoru Kanno 316 NTT Software Corporation 318 Phone: +81-45-212-9803 319 Fax: +81-45-212-9800 320 Email: kanno.satoru@po.ntts.co.jp 322 Kenneth Raeburn 323 Massachusetts Institute of Technology 325 Email: raeburn@mit.edu 327 Masayuki Kanda 328 NTT 330 Phone: +81-422-59-3456 331 Fax: +81-422-59-4015 332 Email: kanda.masayuki@lab.ntt.co.jp 334 Thomas Hardjono 335 Massachusetts Institute of Technology 337 Email: hardjono@mit.edu