idnits 2.17.00 (12 Aug 2021) /tmp/idnits10352/draft-kanno-krbwg-camellia-ccm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 18, 2010) is 4287 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: 'RFC2898' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'ISO-18033-3' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 402, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Downref: Normative reference to an Informational RFC: RFC 3713 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-108' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38B' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38C' -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Kanno 3 Internet-Draft NTT Software Corporation 4 Intended status: Standards Track L. Howard 5 Expires: February 19, 2011 PADL Software Ltd 6 T. Yu 7 T. Hardjono 8 MIT Kerberos Consortium 9 August 18, 2010 11 Kerberos Support for Camellia Cipher in CCM Mode 12 draft-kanno-krbwg-camellia-ccm-03 14 Abstract 16 This draft proposes the Kerberos (v5) support for the Camellia Cipher 17 in Counter with CBC-MAC (CCM) mode. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 19, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Key Representation . . . . . . . . . . . . . . . . . 3 56 4. Key Generation from Pass Phrases or Random Data . . . . . . . 3 57 5. Kerberos Algorithm Profile Parameters . . . . . . . . . . . . 4 58 6. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 11.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 This document defines encryption key and checksum types for Kerberos 72 (v5) using the Camellia algorithm in Counter with CBC-MAC (CCM) Mode 73 [SP800-38C]. The Camellia cipher was developed by NTT and Mitsubishi 74 Electric Corporation in 2000. These new types support 128-bit block 75 encryption and key sizes of 128 or 256 bits. The Camellia algorithm 76 and its properties are described in [RFC3713]. 78 There are a number of motivations to providing support for Camellia 79 in Kerberos v5. Among others, it is desirable to provide an 80 alternate cipher should weaknesses be discovered in the AES and SHA- 81 256 algorithms which are predominant today. Additionally, due to the 82 international user-base of Kerberos, supporting additional ciphers in 83 key markets allows easier adoption and deployment of Kerberos in 84 those regions. 86 Because the encryption types use the CCM mode, they do not rely on a 87 hash algorithm to ensure message integrity. To preserve this 88 property, the corresponding checksum types use the CMAC algorithm 89 [SP800-38B]. 91 For key derivation, the encryption and checksum types use KDF in 92 feedback mode as described in [SP800-108], with CMAC as the 93 underlying pseudo-random function. 95 2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Protocol Key Representation 103 The profile in [RFC3961] treats keys and random octet strings as 104 conceptually different. But since the Camellia key space is dense, 105 we can use any bit string of appropriate length as a key. We use the 106 byte representation for the key described in [RFC3713], where the 107 first bit of the bit string is the high bit of the first byte of the 108 byte string (octet string) representation. 110 4. Key Generation from Pass Phrases or Random Data 112 Given the above format for keys, we can generate keys from the 113 appropriate amounts of random data (128 or 256 bits) by simply 114 copying the input string. To generate an encryption key from a pass 115 phrase and salt string, we use a slight variation on the equivalent 116 algorithm described in section 4 of [RFC3962]. To ensure that 117 different long-term keys are used with Camellia and AES, we prepend 118 the enctype name to the salt string, separated by a null byte. The 119 enctype name is "camellia128-ccm-128" or "camellia256-ccm-128" 120 (without the quotes). 122 saltp = enctype-name | 0x00 | salt 124 tkey = random2key(PBKDF2(passphrase, saltp, iter_count, keylength)) 126 key = DK(tkey, "kerberos") 128 The pseudo-random function used by PBKDF2 is unchanged from section 4 129 of [RFC3962], as is the default iteration count if no string-to-key 130 parameters are supplied. 132 5. Kerberos Algorithm Profile Parameters 134 This is a summary of the parameters to be used with the simplified 135 algorithm profile described in [RFC3961]. 137 Cryptosystem from CCM Profile 138 ------------------------------------------------------------------------ 139 protocol key format As given. 141 specific key structure Two protocol-format keys: { Kc, Ke }. 143 key-generation seed As given. 144 length 146 required checksum As defined below. 147 mechanism 149 cipher state counter index i, expressed as q octets in 150 big-endian order 152 initial cipher state i = 0 154 encryption function adata = associated data 155 adata_pad = shortest string of zero octets to 156 bring adata to a length that is a 157 multiple of the block size 158 plaintext_pad = shortest string of zero octets 159 to bring plaintext to a length 160 that is a multiple of the 161 block size 162 N = random nonce of length n 163 Q = binary representation of octet length of 164 plaintext of length q 165 i = counter index 166 m = number of blocks 167 B0 = Flags | N | Q 168 Ctr0 = Flags | N | oldstate.i 169 T = CBC-MAC(Ke, B0 | adata_len | 170 adata_pad | pad | plaintext | pad) 171 (H1, Ctr1) = E(Ke, T, Ctr0) 172 (C1, Ctrm) = E(Ke, plaintext, Ctr1) 173 ciphertext = N | C1 | H1 174 newstate.i = Ctrm.i 176 decryption function (N,C1,H1) = ciphertext 177 Ctr0 = Flags | N | oldstate.i 178 (T, Ctr1) = D(Ke, H1, Ctr0) 179 (P1, Ctrm) = D(Ke, C1, Ctr1) 180 if (T != CBC-MAC(Ke, B0 | adata_len | 181 adata | adata_pad | plaintext | pad)) 182 report error 183 newstate.i = Ctrm.i 185 default string-to-key As given. 186 params 188 pseudo-random function PRF = CMAC(DK(protocol-key, prfconstant), 189 octet-string) 191 The "prfconstant" used in the PRF operation 192 is the three-octet string "prf". 193 CMAC is defined in [SP800-38B]. The 194 underlying cipher is the associated 195 cryptosystem of the encryption type. 197 key generation functions: 199 string-to-key function As given. 201 random-to-key function As given. 203 key-derivation function The "well-known constant" used for the DK 204 function is the key usage number, expressed as 205 four octets in big-endian order, followed by 206 one octet indicated below. 208 Kc = DK(base-key, usage | 0x99); 209 Ke = DK(base-key, usage | 0xCC); 211 where 213 DK(Key, Constant) = random-to-key(DR(Key, 214 Constant)) 215 K0 = zeros 216 Ki = CMAC(Key, K(i-1) | i | Constant | 217 0x00 | Length(DK)) 218 DR(Key, Constant) = k-truncate(K1 | K2 | 219 K3 | K4 ...) 221 i, Length expressed as four octets in big- 222 endian order 224 Checksum Mechanism from CCM Profile 225 -------------------------------------------------- 226 associated cryptosystem As defined above. 228 get_mic CMAC(Kc, message) 230 verify_mic get_mic and compare 232 Figure 1 234 +--------------------------------------------------------------------+ 235 | protocol key format 128- or 256-bit string | 236 | | 237 | string-to-key function PBKDF2+DK with variable | 238 | iteration count (see | 239 | above) and salt given by | 240 | type-name | 0x00 | salt | 241 | | 242 | type-name is "camellia | 243 | 128-ccm-128" or "camellia | 244 | 256-ccm-128" (without the | 245 | quotes). salt is the | 246 | original input to the | 247 | string-to-key function. | 248 | | 249 | default string-to-key parameters 00 00 10 00 | 250 | | 251 | key-generation seed length key size | 252 | | 253 | random-to-key function identity function | 254 | | 255 | nonce length, n 12 octets (96 bits) | 256 | | 257 | tag length, t 16 octets (128 bits) | 258 | | 259 | counter length, q 3 octets (24 bits) | 260 | | 261 | message block size, m 1 octet | 262 | | 263 | encryption/decryption functions, Camellia in CTR mode | 264 | E and D (cipher block size 16 | 265 | octets), with counter | 266 | block as cipher state | 267 +--------------------------------------------------------------------+ 269 +--------------------------------------------------------------------+ 270 | encryption types | 271 +--------------------------------------------------------------------+ 272 | type-name etype value key size | 273 +--------------------------------------------------------------------+ 274 | camellia128-ccm-128 TBD 128 | 275 | camellia256-ccm-128 TBD 256 | 276 +--------------------------------------------------------------------+ 278 +--------------------------------------------------------------------+ 279 | checksum types | 280 +--------------------------------------------------------------------+ 281 | type-name sumtype value length | 282 +--------------------------------------------------------------------+ 283 | cmac-128-camellia128 TBD 128 | 284 | cmac-128-camellia256 TBD 128 | 285 +--------------------------------------------------------------------+ 287 Figure 2 289 6. Assigned numbers 291 TBD 293 7. IANA Considerations 295 Kerberos encryption and checksum type values used in section 7 were 296 previously reserved in [RFC3961] for the mechanisms defined in this 297 document. The registries have been updated to list this document as 298 the reference. 300 8. Security Considerations 302 At the time of writing this document, there are no known weak keys 303 for Camellia, and no security problem has been found on Camellia (see 304 [NESSIE], [CRYPTREC], and [LNCS]). 306 The CCM mode requires a unique nonce for each message. If two 307 messages use the same nonce, the XOR of the plain texts of the 308 messages can be recovered without the key, compromising the 309 confidentiality of the messages. Kerberos can only probabilistically 310 ensure nonce uniqueness by choosing random nonce values. Since the 311 length of the nonce is 96 bits, the probability of a collision 312 becomes significant as the number of observed messages approaches 313 2^48. 315 CCM was chosen over GCM partly in order to minimize the impact of a 316 nonce collision. Under GCM, a nonce collision results not only in a 317 loss of confidentiality of the plaintexts, but also in the ability to 318 construct forged messages. 320 9. Test Vectors 322 TBD 324 10. Acknowledgements 326 We would like to thank Greg Hudson for the review and corrections to 327 this draft. 329 11. References 331 11.1. Normative References 333 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 334 Specification Version 2.0", RFC 2898, September 2000. 336 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 337 the Camellia Encryption Algorithm", RFC 3713, April 2004. 339 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 340 Kerberos 5", RFC 3961, February 2005. 342 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 343 Encryption for Kerberos 5", RFC 3962, February 2005. 345 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 346 Kerberos Network Authentication Service (V5)", RFC 4120, 347 July 2005. 349 [SP800-108] 350 Chen, L., "Recommendation for Key Derivation Using 351 Pseudorandom Functions", NIST Special Publication 800-108, 352 October 2009, . 355 [SP800-38B] 356 Dworkin, M., "Recommendation for Block Cipher Modes of 357 Operation: The CMAC Mode for Authentication", NIST Special 358 Publication 800-38B, May 2005, . 361 [SP800-38C] 362 Dworkin, M., "Recommendation for Block Cipher Modes of 363 Operation: the CCM Mode for Authentication and 364 Confidentiality", NIST Special Publication 800-38C, 365 July 2007, . 368 11.2. Informative References 370 [CRYPTREC] 371 Information-technology Promotion Agency (IPA), 372 "Cryptography Research and Evaluation Committees", 373 . 375 [ISO-18033-3] 376 International Standards Organization, "Information 377 technology - Security techniques - Encryption algorithms 378 -- Part 3: Block ciphers (AES, Camellia, SEED)", 379 July 2010. 381 [LNCS] Mala, H., Shakiba, M., and M. Dakhil-alian, "New Results 382 on Impossible Differential Cryptanalysis of Reduced Round 383 Camellia-128", LNCS 5867, November 2009, 384 . 386 [MIT-Athena] 387 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 388 Authentication Service for Open Network Systems. In 389 Proceedings of the Winter 1988 Usenix Conference. 390 February.", 1988. 392 [NESSIE] "The NESSIE project (New European Schemes for Signatures, 393 Integrity and Encryption)", 394 . 396 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 397 Authentication Service (V5)", RFC 1510, September 1993. 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 403 Text on Security Considerations", BCP 72, RFC 3552, 404 July 2003. 406 Appendix A. Additional Stuff 408 This becomes an Appendix. 410 Authors' Addresses 412 Satoru Kanno 413 NTT Software Corporation 415 Phone: +81-45-212-9803 416 Email: kanno.satoru@po.ntts.co.jp 418 Luke Howard 419 PADL Software Ltd 421 Email: lukeh@padl.com 423 Tom Yu 424 MIT Kerberos Consortium 426 Email: tlyu@mit.edu 428 Thomas Hardjono 429 MIT Kerberos Consortium 431 Email: hardjono@mit.edu