Kerberos Working Group K. Raeburn Updates: Kerberos-revisions MIT Document: draft-raeburn-krb-rijndael-krb-00.txt November 17, 2000 Rijndael, Twofish, and Serpent 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. 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. The other AES finalists Raeburn [Page 1] INTERNET DRAFT November 2000 appear more problematic from an intellectual property perspective (involving licenses or patents), and so are not being addressed by the author. Each of these algorithms, as required by the AES specifications, supports 128-bit block encryption. Longer block sizes are also supported by some of these algorithms, but will not be used in Kerberos. Each of these algorithms permits 128-, 192- and 256-bit keys. Their use in Kerberos will permit all of these key sizes. The Twofish specification also describes a means for handling other key sizes in between. Keys of these other sizes are effectively converted into 192- or 256-bit keys. In order to avoid having multiple representations of a single key causing potential confusion, and to simplify the key derivation specification, Twofish keys in Kerberos will always be 128, 192, or 256 bits long. The EncryptedData objects are generated as described in [Kerb] for des3-cbc-hmac-sha1, using one of the above encryption algorithms in CBC mode, and a checksum algorithm of HMAC-SHA256. Unless otherwise specified, a zero initial vector must be used for CBC mode. (Q: Will NIST's new modes of operation include anything we might prefer over CBC-encrypt plus checksum? Should we go ahead with this anyways?) These new cryptosystems will use key derivation as described in [Kerb], with derived keys having the same length as the original keys. The new keys will be the byte sequences generated from the key derivation algorithm; no adjustments (such as creating parity bits for triple-DES) are needed. Thus the number of bits required as output are the same as the key size. (Open question: Should we drop key derivation? The author is somewhat but not overwhelmingly or, he likes to think, blindly in favor of keeping it. Should we revive the argument the author completely missed when it came up in regard to triple-DES? Perhaps not.) The confounder is one block, prepended to the data. The input data is padded with zero to fifteen trailing zero-valued octets to make it a multiple of the block size. Since the Kerberos protocol always passes around the key type and length as part of the EncryptionKey data, we can take advantage of this when defining checksum types, such that a checksum algorithm can Raeburn [Page 2] INTERNET DRAFT November 2000 accept any length of key, and in the case of key derivation, use the encryption algorithm specified by the key type when deriving a new key. Thus we define only one new value for the sumtype field, for an HMAC using the SHA-256 algorithm. assigned numbers (Cliff?): +--------------------------------------------------------------------+ | encryption types | +--------------------------------------------------------------------+ | type name etype value key sizes | +--------------------------------------------------------------------+ | rijndael-hmac-sha256-kd TBD 128, 192, 256 | | twofish-hmac-sha256-kd TBD 128, 192, 256 | | serpent-hmac-sha256-kd TBD 128, 192, 256 | +--------------------------------------------------------------------+ The alias "aes-hmac-sha256-kd" may be used for whichever of the above types uses the algorithm chosen as the AES, if any. Currently, Rijndael has been chosen, and the final AES will probably be Rijndael in its current form, but the AES FIPS is not completed. We recommend not using this alias until the final AES FIPS is published. (Q: Or, is it definite that there will be no changes?) +--------------------------------------------------------------------+ | checksum types | +--------------------------------------------------------------------+ | type name sumtype value checksum length | +--------------------------------------------------------------------+ | hmac-sha256-kd TBD 256 | +--------------------------------------------------------------------+ (Q: Better to just define hmac-sha256, and say that it uses key derivation when the specified key type demands it?) The checksum type hmac-sha256-kd will be used with the encryption types defined above. (Similarly, the hmac-sha1-des3 and hmac-sha1-des3-kd checksum types in [Kerb] could be extended to be generic hmac-sha1 and hmac-sha1-kd checksums, making use of as much key data as is supplied, and the specified encryption algorithm. Since this document isn't making use of SHA-1, such changes are outside its scope.) 4. Key Generation From Pass Phrases As the des3-cbc-hmac-sha1-kd encryption type is specified in [Kerb], Raeburn [Page 3] INTERNET DRAFT November 2000 the recommended algorithm for generating a key from a pass phrase (primarily for users' long-term keys, as is assumed in the descriptive text here, but also occasionally for other purposes) involves n-folding the pass phrase to produce an intermediate encryption key, which is fed into the key derivation algorithm with a well-known constant to produce the final key of the user. While the n-fold function does cause the bits of the input string to contribute equally to the output ([n-fold]), there are cases in which it does a poor job of entropy preservation, and indeed entropy preservation was never described as a property of the algorithm in the original paper. Thus for these algorithms we use the new NIST hash function SHA-256 in generating the intermediate key. The catenation of salt and UTF-8 pass phrase is passed to the SHA-256 function. The two halves of the hash function output are XORed together to get a 128-bit intermediate key. This key is passed into the key derivation algorithm with the constant string "kerberos" as in [Kerb]. The resulting 128-bit key is the user's long-term key. Since in general memorable pass phrases will give nowhere near one block's worth of entropy, the author sees no need to make this algorithm capable of generating longer keys at this time. Sample test vectors are given in the appendix. (Q: Any weak keys?) 5. Recommendations Rijndael, as the proposed AES cipher, is strongly RECOMMENDED. 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 resistance to certain types of possible attacks, are OPTIONAL. 6. Implementation notes Preauthentication algorithms involving smart cards or other hardware may provide additional unpredictability that may be used to generate longer keys, or simply be factored into a stronger new 128-bit key. Such schemes are outside the scope of this document, but implementors should recognize that using longer keys with these algorithms for AS_REP messages and preauth data may be plausible. 7. Security Considerations These new algorithms have not been around long enough to receive the Raeburn [Page 4] INTERNET DRAFT November 2000 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. 8. 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., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos- revisions-06.txt, July 14, 2000. Work in progress. [Rijn] Daemen, J., Rijmen, V., "AES Proposal: Rijndael", September 3, 1999. * [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. [Serp] Anderson, R., Biham, E., Knudsen, L., "Serpent: A Proposal for the Advanced Encryption Standard", June 1998. * [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October, 1996. [SHA256] NIST doc ... * [n-fold] Blumenthal & Bellovin ... * Need more substantial references (RFCs or published papers) if possible; web-accessible copy may not be a permanent reference. 9. Author's Address Raeburn [Page 5] INTERNET DRAFT November 2000 Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 10. Full Copyright Statement Copyright (C) The Internet Society (2000). 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." A. Sample test vectors Some sample test vectors for the string-to-key algorithm: (values to be filled in later) Salt: none Pass phrase: "test" 74 65 73 74 SHA-256 folded to intermediate key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Raeburn [Page 6] INTERNET DRAFT November 2000 Twofish key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Salt: "ATHENA.MIT.EDUraeburn" Pass phrase: "password" ... SHA-256 folded to intermediate key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Salt: none Pass phrase: something with a variety of non-ASCII characters ... SHA-256 folded to intermediate key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Rijndael key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Twofish key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Serpent key: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx Raeburn [Page 7]