idnits 2.17.00 (12 Aug 2021) /tmp/idnits13362/draft-raeburn-krb-rijndael-krb-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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 Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 52 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([AES], [Kerb]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 2, 2001) is 7627 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: 'Rijn' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'Serp' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'Twof' is defined on line 249, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' == Outdated reference: A later version (-10) exists of draft-ietf-cat-kerberos-revisions-08 -- Possible downref: Normative reference to a draft: ref. 'Kerb' ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) -- Possible downref: Non-RFC (?) normative reference: ref. 'Rijn' -- Possible downref: Non-RFC (?) normative reference: ref. 'Serp' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA256' -- Possible downref: Non-RFC (?) normative reference: ref. 'Twof' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group K. Raeburn 3 Updates: Kerberos-revisions MIT 4 Document: draft-raeburn-krb-rijndael-krb-01.txt July 2, 2001 6 Rijndael, Serpent, and Twofish Cryptosystems 7 for Kerberos 5 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 13 are working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. Internet-Drafts are 16 draft documents valid for a maximum of six months and may be updated, 17 replaced, or obsoleted by other documents at any time. It is 18 inappropriate to use Internet-Drafts as reference material or to cite 19 them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1. Abstract 29 The AES competition in the US [AES] has prompted the submission and 30 analysis of a number of new ciphers intended to be significantly 31 stronger and faster than the old DES algorithm. This document 32 describes the addition of some of these algorithms to the Kerberos 33 cryptosystem suite [Kerb]. 35 Comments should be sent to the author, or to the IETF Kerberos 36 working group (ietf-krb-wg@anl.gov). 38 2. Conventions Used in this Document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119. 44 3. New Encryption and Checksum Types 46 This document defines encryption key and checksum types for Kerberos 47 5 to be used with the Rijndael (chosen by NIST as the AES cipher), 48 Twofish and Serpent encryption algorithms. 50 Each of these algorithms, as required by the AES specifications, 51 supports 128-bit block encryption, and key sizes of 128, 192, or 256 52 bits. Other block sizes and key sizes are also supported by some of 53 these algorithms, but are not considered here. 55 Using the "simplified profile" of section 6 of [Kerb], we can define 56 a group of encryption and checksum schemes. The basic encryption 57 algorithms listed above are used in CBC mode, with a zero initial 58 vector. The associated checksum function is the function from 59 [SHA256] with an output size of twice the key size (SHA256, SHA384, 60 or SHA512). 62 We use the above encryption algorithms in CBC mode, and a hash 63 algorithm of SHA256, SHA384, or SHA512 [SHA256], with the hash size 64 twice the size of the encryption key, in the "simplified profile" of 65 section 6 of [Kerb]. (As of the time of this writing, NIST is 66 reviewing several new proposed modes of operation, some of which may 67 permit encryption and integrity protection simultaneously. Once this 68 process is done, we may wish to consider using one of these modes to 69 define a new profile.) Unless otherwise specified, a zero initial 70 vector must be used for CBC mode. 72 4. Key Generation From Pass Phrases 74 For each of these new encryption/checksum profiles, we define a 75 process for generating a key from a pass phrase and salt string, both 76 assumed to be supplied in UTF-8 representation. 78 We use the PBKDF2 function from PKCS #5 v2.0 ([RFC2898]), with 79 parameters indicated below, to generate an intermediate key, which is 80 passed into the key derivation algorithm with the constant string 81 "kerberos" as in [Kerb]. The resulting key is the user's long-term 82 key for use with the encryption algorithm in question: 84 tkey = PBKDF2 (passphrase, salt, 2, keylength) 85 key = DK(tkey, "kerberos") 87 (As defined, PBKDF2 actually generates a random byte string, and the 88 PKCS #5 spec assumes that the key space is dense. For the pedantic, 89 we get a "random byte string" from PBKDF2, and pass it through the 90 random-to-key function in the profile -- which we define as a simple 91 copy operation -- to get a "key".) 93 The pseudorandom function used by PBKDF2 will be an HMAC of the 94 passphrase and salt, as described in Appendix B.1 to PKCS#5, but 95 using the hash function chosen for the encryption algorithm instead 96 of SHA-1. For example, all of the 192-bit-key profiles will use an 97 HMAC based on SHA384. 99 Note that since the hash function's output block size is larger than 100 the key sizes, only one block needs to be generated through the 101 PBKDF2 algorithm, and only two iterations are specified. Thus, using 102 the notation from PKCS#5, the intermediate key is given by: 104 U_1 = PRF(P, S || INT(0)) 105 U_2 = PRF(P, U_1) 106 tmp = U_1 \xor U_2 107 tkey = tmp<0..keylength-1> 109 Sample test vectors are given in the appendix. 111 5. Kerberos Algorithm Profile Parameters 113 This is a summary of the parameters to be used with the simplified 114 algorithm profile described in section 6.4.2 of [Kerb]: 116 +--------------------------------------------------------------------+ 117 | protocol key format simple byte string of | 118 | 128, 192 or 256 bits | 119 | | 120 | string-to-key function PBKDF2+DK (see previous | 121 | section) | 122 | | 123 | key-generation seed key size | 124 | length | 125 | | 126 | random-to-key function identity | 127 | | 128 | hash function SHA-256, -384 or -512 | 129 | with output size twice | 130 | the key size | 131 | | 132 | block size 128 bits | 133 | | 134 | encryption and Rijndael, Serpent or | 135 | decryption functions Twofish, in CBC mode | 136 | with zero ivec | 137 +--------------------------------------------------------------------+ 139 Expanding on the set of key sizes and the set of encryption 140 functions, this gives us nine profiles for encryption and checksum 141 algorithm pairs. 143 6. Assigned Numbers (Cliff? IANA?) 145 The following encryption type numbers are assigned: 147 +--------------------------------------------------------------------+ 148 | encryption types | 149 +--------------------------------------------------------------------+ 150 | type name etype value key size | 151 +--------------------------------------------------------------------+ 152 | rijndael128-hmac-sha256 TBD 128 | 153 | rijndael192-hmac-sha384 TBD 192 | 154 | rijndael256-hmac-sha512 TBD 256 | 155 | serpent128-hmac-sha256 TBD 128 | 156 | serpent192-hmac-sha384 TBD 192 | 157 | serpent256-hmac-sha512 TBD 256 | 158 | twofish128-hmac-sha256 TBD 128 | 159 | twofish192-hmac-sha384 TBD 192 | 160 | twofish256-hmac-sha512 TBD 256 | 161 +--------------------------------------------------------------------+ 163 Where implementations accept type names in human-readable form, the 164 alternative names "aes128-hmac-sha256", "aes192-hmac-sha384" and 165 "aes256-hmac-sha512" are recommended to be permitted as aliases for 166 the Rijndael key types. 168 The following checksum type numbers are assigned: 170 +--------------------------------------------------------------------+ 171 | checksum types | 172 +--------------------------------------------------------------------+ 173 | type name sumtype value length | 174 +--------------------------------------------------------------------+ 175 | hmac-sha256-rijndael128 TBD 256 | 176 | hmac-sha384-rijndael192 TBD 384 | 177 | hmac-sha512-rijndael256 TBD 512 | 178 | hmac-sha256-serpent128 TBD 256 | 179 | hmac-sha384-serpent192 TBD 384 | 180 | hmac-sha512-serpent256 TBD 512 | 181 | hmac-sha256-twofish128 TBD 256 | 182 | hmac-sha384-twofish192 TBD 384 | 183 | hmac-sha512-twofish256 TBD 512 | 184 +--------------------------------------------------------------------+ 186 These checksum types will be used with the corresponding encryption 187 types defined above. Aliases "hmac-sha256-aes128" and so forth are 188 suggested for the checksum types associated with Rijndael keys. 190 7. Recommendations 192 Rijndael, as the proposed AES cipher, is strongly RECOMMENDED, with 193 all three lengths. 195 Twofish and Serpent, described in the AES report as weaker that 196 Rijndael in terms of performance or implementability in certain 197 environments but stronger in terms of anticipated resistance to 198 certain types of possible attacks, are OPTIONAL. 200 8. Security Considerations 202 These new algorithms have not been around long enough to receive the 203 decades of intense analysis that DES has received. It is possible 204 that some weakness exists that has not been found by the 205 cryptosystems' authors or other cryptographers analyzing these 206 algorithms before and during the AES competition. The AES report 207 does indicate that arguments were put forth relating to this in favor 208 of deploying multiple algorithms in case one is found to be 209 significantly weaker than previously believed. 211 The 256-bit SHA algorithm is a work in progress by the US National 212 Institute of Standards and Technology. To the best of the author's 213 knowledge, the review process has not been completed. The use of 214 this algorithm in this document is with the assumption that the 215 standardization process will go smoothly. 217 The author is not a cryptographer. 219 9. Acknowledgements 221 Thanks to John Brezak for feedback on earlier versions of this 222 document. 224 10. References 226 [AES] Nechvatal, J., Barker, E., Bassham, L., Burr, W., Dworkin, M., 227 Foti, J., Roback, E., "Report on the Development of the Advanced 228 Encryption Standard (AES)", National Institute of Standards and 229 Technology, October 2, 2000. 231 [Kerb] Neuman, C., Kohl, J., Ts'o, T., Raeburn, K., Yu, T., "The 232 Kerberos Network Authentication Service (V5)", draft-ietf-cat- 233 kerberos-revisions-08.txt, March 2, 2001. Work in progress. 235 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 236 3", RFC 2026, October, 1996. 238 [RFC2898] Kaliski, B., "PKCS #5: Passowrd-Based Cryptography 239 Specification Version 2.0", RFC 2898, September 2000. 241 [Rijn] Daemen, J., Rijmen, V., "AES Proposal: Rijndael", September 3, 242 1999. * 244 [Serp] Anderson, R., Biham, E., Knudsen, L., "Serpent: A Proposal for 245 the Advanced Encryption Standard", June 1998. * 247 [SHA256] NIST doc ... * 249 [Twof] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, C., 250 Ferguson, N., "The Twofish Encrytion Algorithm: A 128-Bit Block 251 Cipher", Wiley Computer Publishing, 1999. 253 * Need more substantial references (RFCs or published papers) if 254 possible; web-accessible copy may not be a permanent reference. 256 11. Author's Address 258 Kenneth Raeburn 259 Massachusetts Institute of Technology 260 77 Massachusetts Avenue 261 Cambridge, MA 02139 262 raeburn@mit.edu 264 12. Full Copyright Statement 266 Copyright (C) The Internet Society (2001). All Rights Reserved. 268 This document and translations of it may be copied and furnished to 269 others, and derivative works that comment on or otherwise explain it 270 or assist in its implementation may be prepared, copied, published 271 and distributed, in whole or in part, without restriction of any 272 kind, provided that the above copyright notice and this paragraph are 273 included on all such copies and derivative works. However, this 274 document itself may not be modified in any way, such as by removing 275 the copyright notice or references to the Internet Society or other 276 Internet organizations, except as needed for the purpose of 277 developing Internet standards in which case the procedures for 278 copyrights defined in the Internet Standards process must be 279 followed, or as required to translate it into languages other than 280 English. 282 The limited permissions granted above are perpetual and will not be 283 revoked by the Internet Society or its successors or assigns. 285 This document and the information contained herein is provided on an 286 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 287 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 288 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 289 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 290 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 292 A. Sample test vectors 294 Some sample test vectors for the string-to-key algorithm: 296 (values to be filled in later) 298 Pass phrase: "test" 299 Salt: none 300 74 65 73 74 301 PBKDF2 128-bit output (intermediate key): 302 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 303 Rijndael 128-bit key: 304 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 305 Serpent 128-bit key: 306 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 307 Twofish 128-bit key: 308 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 309 PBKDF2 192-bit output (intermediate key): 310 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 311 xx xx xx xx xx xx xx xx 312 Rijndael 192-bit key: 313 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 314 xx xx xx xx xx xx xx xx 315 Serpent 192-bit key: 316 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 317 xx xx xx xx xx xx xx xx 318 Twofish 192-bit key: 319 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 320 xx xx xx xx xx xx xx xx 321 PBKDF2 256-bit output (intermediate key): 322 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 323 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 324 Rijndael 256-bit key: 325 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 326 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 327 Serpent 256-bit key: 328 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 329 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 330 Twofish 256-bit key: 331 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 332 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 334 Pass phrase: "password" 335 70 61 73 73 77 6f 72 64 336 Salt: "ATHENA.MIT.EDUraeburn" 337 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 338 65 62 75 72 6e 339 PBKDF2 128-bit output (intermediate key): 340 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 341 Rijndael 128-bit key: 342 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 343 Serpent 128-bit key: 344 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 345 Twofish 128-bit key: 346 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 347 PBKDF2 192-bit output (intermediate key): 348 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 349 xx xx xx xx xx xx xx xx 350 Rijndael 192-bit key: 351 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 352 xx xx xx xx xx xx xx xx 353 Serpent 192-bit key: 354 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 355 xx xx xx xx xx xx xx xx 356 Twofish 192-bit key: 357 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 358 xx xx xx xx xx xx xx xx 359 PBKDF2 256-bit output (intermediate key): 360 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 361 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 362 Rijndael 256-bit key: 363 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 364 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 365 Serpent 256-bit key: 366 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 367 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 368 Twofish 256-bit key: 369 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 370 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 372 Pass phrase: eszett 373 c3 9f 374 Salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 375 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 4a 75 376 72 69 c5 a1 69 c4 87 377 PBKDF2 128-bit output (intermediate key): 378 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 379 Rijndael 128-bit key: 380 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 382 Serpent 128-bit key: 383 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 384 Twofish 128-bit key: 385 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 386 PBKDF2 192-bit output (intermediate key): 387 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 388 xx xx xx xx xx xx xx xx 389 Rijndael 192-bit key: 390 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 391 xx xx xx xx xx xx xx xx 392 Serpent 192-bit key: 393 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 394 xx xx xx xx xx xx xx xx 395 Twofish 192-bit key: 396 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 397 xx xx xx xx xx xx xx xx 398 PBKDF2 256-bit output (intermediate key): 399 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 400 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 401 Rijndael 256-bit key: 402 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 403 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 404 Serpent 256-bit key: 405 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 406 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 407 Twofish 256-bit key: 408 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 409 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 411 B. Change History 413 Delete this section before RFC publication. 415 Major changes from -00: 417 Define different types based on key/hash sizes, with hash size always 418 twice key size. Use simplified profile of revised section 6 of 419 RFC1510bis. Drop "-kd" from the names. 421 Use PKCS#5 instead of simple hash. Changed string-to-key vector to 422 use some "Appendix Z" cases also submitted for kerberos-revisions.