Kerberos Working Group K. Raeburn Updates: Kerberos-revisions MIT Document: draft-raeburn-krb-rijndael-krb-01.txt July 2, 2001 Rijndael, Serpent, and Twofish Cryptosystems for Kerberos 5 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The AES competition in the US [AES] has prompted the submission and analysis of a number of new ciphers intended to be significantly stronger and faster than the old DES algorithm. This document describes the addition of some of these algorithms to the Kerberos cryptosystem suite [Kerb]. Comments should be sent to the author, or to the IETF Kerberos working group (ietf-krb-wg@anl.gov). 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. New Encryption and Checksum Types This document defines encryption key and checksum types for Kerberos 5 to be used with the Rijndael (chosen by NIST as the AES cipher), Twofish and Serpent encryption algorithms. Raeburn [Page 1]
INTERNET DRAFT May 2001 Each of these algorithms, as required by the AES specifications, supports 128-bit block encryption, and key sizes of 128, 192, or 256 bits. Other block sizes and key sizes are also supported by some of these algorithms, but are not considered here. Using the "simplified profile" of section 6 of [Kerb], we can define a group of encryption and checksum schemes. The basic encryption algorithms listed above are used in CBC mode, with a zero initial vector. The associated checksum function is the function from [SHA256] with an output size of twice the key size (SHA256, SHA384, or SHA512). We use the above encryption algorithms in CBC mode, and a hash algorithm of SHA256, SHA384, or SHA512 [SHA256], with the hash size twice the size of the encryption key, in the "simplified profile" of section 6 of [Kerb]. (As of the time of this writing, NIST is reviewing several new proposed modes of operation, some of which may permit encryption and integrity protection simultaneously. Once this process is done, we may wish to consider using one of these modes to define a new profile.) Unless otherwise specified, a zero initial vector must be used for CBC mode. 4. Key Generation From Pass Phrases For each of these new encryption/checksum profiles, we define a process for generating a key from a pass phrase and salt string, both assumed to be supplied in UTF-8 representation. We use the PBKDF2 function from PKCS #5 v2.0 ([RFC2898]), with parameters indicated below, to generate an intermediate key, which is passed into the key derivation algorithm with the constant string "kerberos" as in [Kerb]. The resulting key is the user's long-term key for use with the encryption algorithm in question: tkey = PBKDF2 (passphrase, salt, 2, keylength) key = DK(tkey, "kerberos") (As defined, PBKDF2 actually generates a random byte string, and the PKCS #5 spec assumes that the key space is dense. For the pedantic, we get a "random byte string" from PBKDF2, and pass it through the random-to-key function in the profile -- which we define as a simple copy operation -- to get a "key".) The pseudorandom function used by PBKDF2 will be an HMAC of the passphrase and salt, as described in Appendix B.1 to PKCS#5, but using the hash function chosen for the encryption algorithm instead of SHA-1. For example, all of the 192-bit-key profiles will use an HMAC based on SHA384. Raeburn [Page 2]
INTERNET DRAFT May 2001 Note that since the hash function's output block size is larger than the key sizes, only one block needs to be generated through the PBKDF2 algorithm, and only two iterations are specified. Thus, using the notation from PKCS#5, the intermediate key is given by: U_1 = PRF(P, S || INT(0)) U_2 = PRF(P, U_1) tmp = U_1 \xor U_2 tkey = tmp<0..keylength-1> Sample test vectors are given in the appendix. 5. Kerberos Algorithm Profile Parameters This is a summary of the parameters to be used with the simplified algorithm profile described in section 6.4.2 of [Kerb]: +--------------------------------------------------------------------+ | protocol key format simple byte string of | | 128, 192 or 256 bits | | | | string-to-key function PBKDF2+DK (see previous | | section) | | | | key-generation seed key size | | length | | | | random-to-key function identity | | | | hash function SHA-256, -384 or -512 | | with output size twice | | the key size | | | | block size 128 bits | | | | encryption and Rijndael, Serpent or | | decryption functions Twofish, in CBC mode | | with zero ivec | +--------------------------------------------------------------------+ Expanding on the set of key sizes and the set of encryption functions, this gives us nine profiles for encryption and checksum algorithm pairs. 6. Assigned Numbers (Cliff? IANA?) The following encryption type numbers are assigned: Raeburn [Page 3]
INTERNET DRAFT May 2001 +--------------------------------------------------------------------+ | encryption types | +--------------------------------------------------------------------+ | type name etype value key size | +--------------------------------------------------------------------+ | rijndael128-hmac-sha256 TBD 128 | | rijndael192-hmac-sha384 TBD 192 | | rijndael256-hmac-sha512 TBD 256 | | serpent128-hmac-sha256 TBD 128 | | serpent192-hmac-sha384 TBD 192 | | serpent256-hmac-sha512 TBD 256 | | twofish128-hmac-sha256 TBD 128 | | twofish192-hmac-sha384 TBD 192 | | twofish256-hmac-sha512 TBD 256 | +--------------------------------------------------------------------+ Where implementations accept type names in human-readable form, the alternative names "aes128-hmac-sha256", "aes192-hmac-sha384" and "aes256-hmac-sha512" are recommended to be permitted as aliases for the Rijndael key types. The following checksum type numbers are assigned: +--------------------------------------------------------------------+ | checksum types | +--------------------------------------------------------------------+ | type name sumtype value length | +--------------------------------------------------------------------+ | hmac-sha256-rijndael128 TBD 256 | | hmac-sha384-rijndael192 TBD 384 | | hmac-sha512-rijndael256 TBD 512 | | hmac-sha256-serpent128 TBD 256 | | hmac-sha384-serpent192 TBD 384 | | hmac-sha512-serpent256 TBD 512 | | hmac-sha256-twofish128 TBD 256 | | hmac-sha384-twofish192 TBD 384 | | hmac-sha512-twofish256 TBD 512 | +--------------------------------------------------------------------+ These checksum types will be used with the corresponding encryption types defined above. Aliases "hmac-sha256-aes128" and so forth are suggested for the checksum types associated with Rijndael keys. 7. Recommendations Rijndael, as the proposed AES cipher, is strongly RECOMMENDED, with all three lengths. Raeburn [Page 4]
INTERNET DRAFT May 2001 Twofish and Serpent, described in the AES report as weaker that Rijndael in terms of performance or implementability in certain environments but stronger in terms of anticipated resistance to certain types of possible attacks, are OPTIONAL. 8. Security Considerations These new algorithms have not been around long enough to receive the decades of intense analysis that DES has received. It is possible that some weakness exists that has not been found by the cryptosystems' authors or other cryptographers analyzing these algorithms before and during the AES competition. The AES report does indicate that arguments were put forth relating to this in favor of deploying multiple algorithms in case one is found to be significantly weaker than previously believed. The 256-bit SHA algorithm is a work in progress by the US National Institute of Standards and Technology. To the best of the author's knowledge, the review process has not been completed. The use of this algorithm in this document is with the assumption that the standardization process will go smoothly. The author is not a cryptographer. 9. Acknowledgements Thanks to John Brezak for feedback on earlier versions of this document. 10. References [AES] Nechvatal, J., Barker, E., Bassham, L., Burr, W., Dworkin, M., Foti, J., Roback, E., "Report on the Development of the Advanced Encryption Standard (AES)", National Institute of Standards and Technology, October 2, 2000. [Kerb] Neuman, C., Kohl, J., Ts'o, T., Raeburn, K., Yu, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat- kerberos-revisions-08.txt, March 2, 2001. Work in progress. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October, 1996. [RFC2898] Kaliski, B., "PKCS #5: Passowrd-Based Cryptography Specification Version 2.0", RFC 2898, September 2000. [Rijn] Daemen, J., Rijmen, V., "AES Proposal: Rijndael", September 3, 1999. * Raeburn [Page 5]
INTERNET DRAFT May 2001 [Serp] Anderson, R., Biham, E., Knudsen, L., "Serpent: A Proposal for the Advanced Encryption Standard", June 1998. * [SHA256] NIST doc ... * [Twof] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, C., Ferguson, N., "The Twofish Encrytion Algorithm: A 128-Bit Block Cipher", Wiley Computer Publishing, 1999. * Need more substantial references (RFCs or published papers) if possible; web-accessible copy may not be a permanent reference. 11. Author's Address Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 raeburn@mit.edu 12. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Raeburn [Page 6]
INTERNET DRAFT May 2001 A. Sample test vectors Some sample test vectors for the string-to-key algorithm: (values to be filled in later) Pass phrase: "test" Salt: none 74 65 73 74 PBKDF2 128-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx PBKDF2 192-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx PBKDF2 256-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Raeburn [Page 7]
INTERNET DRAFT May 2001 Pass phrase: "password" 70 61 73 73 77 6f 72 64 Salt: "ATHENA.MIT.EDUraeburn" 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 65 62 75 72 6e PBKDF2 128-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx PBKDF2 192-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx PBKDF2 256-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Pass phrase: eszett c3 9f Salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 4a 75 72 69 c5 a1 69 c4 87 PBKDF2 128-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Raeburn [Page 8]
INTERNET DRAFT May 2001 Serpent 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 128-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx PBKDF2 192-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 192-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx PBKDF2 256-bit output (intermediate key): xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish 256-bit key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx B. Change History Delete this section before RFC publication. Major changes from -00: Define different types based on key/hash sizes, with hash size always twice key size. Use simplified profile of revised section 6 of RFC1510bis. Drop "-kd" from the names. Use PKCS#5 instead of simple hash. Changed string-to-key vector to use some "Appendix Z" cases also submitted for kerberos-revisions. Raeburn [Page 9]
