< draft-raeburn-krb-rijndael-krb-06.txt   draft-raeburn-krb-rijndael-krb-07.txt >
Kerberos Working Group K. Raeburn
Kerberos Working Group K. Raeburn Document: draft-raeburn-krb-rijndael-krb-07.txt MIT
Document: draft-raeburn-krb-rijndael-krb-06.txt MIT July 19, 2004
March 29, 2004 expires January 19, 2005
expires September 29, 2004
AES Encryption for Kerberos 5 AES Encryption for Kerberos 5
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working working groups. Note that other groups may also distribute working
documents as Internet-Drafts. Internet-Drafts are draft documents documents as Internet-Drafts. Internet-Drafts are draft documents
skipping to change at page 1, line 36 skipping to change at page 1, line 35
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The US National Institute of Standards and Technology has chosen a The US National Institute of Standards and Technology has chosen a
new Advanced Encryption Standard, which is significantly faster and new Advanced Encryption Standard, which is significantly faster and
(it is believed) more secure than the old DES algorithm. This (it is believed) more secure than the old DES algorithm. This
document is a specification for the addition of this algorithm to the document is a specification for the addition of this algorithm to the
Kerberos cryptosystem suite. Kerberos cryptosystem suite.
Comments should be sent to the author, or to the IETF Kerberos
working group (ietf-krb-wg@anl.gov).
1. Introduction 1. Introduction
This document defines encryption key and checksum types for Kerberos This document defines encryption key and checksum types for Kerberos
5 using the AES algorithm recently chosen by NIST. These new types 5 using the AES algorithm recently chosen by NIST. These new types
support 128-bit block encryption, and key sizes of 128 or 256 bits. support 128-bit block encryption, and key sizes of 128 or 256 bits.
Using the "simplified profile" of [KCRYPTO], we can define a pair of Using the "simplified profile" of [KCRYPTO], we can define a pair of
encryption and checksum schemes. AES is used with cipher text encryption and checksum schemes. AES is used with cipher text
stealing to avoid message expansion, and SHA-1 [SHA1] is the stealing to avoid message expansion, and SHA-1 [SHA1] is the
associated checksum function. associated checksum function.
2. Conventions Used in this Document 2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [KEYWORDS].
3. Protocol Key Representation 3. Protocol Key Representation
The profile in [KCRYPTO] treats keys and random octet strings as The profile in [KCRYPTO] treats keys and random octet strings as
conceptually different. But since the AES key space is dense, we can conceptually different. But since the AES key space is dense, we can
use any bit string of appropriate length as a key. We use the byte use any bit string of appropriate length as a key. We use the byte
representation for the key described in [AES], where the first bit of representation for the key described in [AES], where the first bit of
the bit string is the high bit of the first byte of the byte string the bit string is the high bit of the first byte of the byte string
(octet string) representation. (octet string) representation.
skipping to change at page 3, line 7 skipping to change at page 2, line 51
passphrase and salt, as described in Appendix B.1 to PKCS#5. passphrase and salt, as described in Appendix B.1 to PKCS#5.
The number of iterations is specified by the string-to-key parameters The number of iterations is specified by the string-to-key parameters
supplied. The parameter string is four octets indicating an unsigned supplied. The parameter string is four octets indicating an unsigned
number in big-endian order. This is the number of iterations to be number in big-endian order. This is the number of iterations to be
performed. If the value is 00 00 00 00, the number of iterations to performed. If the value is 00 00 00 00, the number of iterations to
be performed is 4294967296 (2**32). (Thus the minimum expressable be performed is 4294967296 (2**32). (Thus the minimum expressable
iteration count is 1.) iteration count is 1.)
For environments where slower hardware is the norm, implementations For environments where slower hardware is the norm, implementations
may wish to limit the number of iterations to prevent a spoofed of protocols such as Kerberos may wish to limit the number of
response from consuming lots of client-side CPU time; it is iterations to prevent a spoofed response supplied by an attacker from
recommended that this bound be no less than 50000. Even for consuming lots of client-side CPU time; if such a limit is
environments with fast hardware, 4 billion iterations is likely to implemented, it SHOULD be no less than 50000. Even for environments
take a fairly long time; much larger bounds might still be enforced, with fast hardware, 4 billion iterations is likely to take a fairly
and it might be wise for implementations to permit interruption of long time; much larger bounds might still be enforced, and it might
this operation by the user if the environment allows for it. be wise for implementations to permit interruption of this operation
by the user if the environment allows for it.
If the string-to-key parameters are not supplied, the value used is If the string-to-key parameters are not supplied, the value used is
00 00 10 00 (decimal 4096, indicating 4096 iterations). 00 00 10 00 (decimal 4096, indicating 4096 iterations).
Note that this is NOT a requirement, nor even a recommendation, for Note that this is not a requirement, nor even a recommendation, for
this value to be used in "optimistic preauthentication" (e.g., this value to be used in "optimistic preauthentication" (e.g.,
attempting timestamp-based preauthentication using the user's long- attempting timestamp-based preauthentication using the user's long-
term key, without having first communicated with the KDC) in the term key, without having first communicated with the KDC) in the
absence of additional information, nor as a default value for sites absence of additional information, nor as a default value for sites
to use for their principals' long-term keys in their Kerberos to use for their principals' long-term keys in their Kerberos
database. It is simply the interpretation of the absence of the database. It is simply the interpretation of the absence of the
string-to-key parameter field when the KDC has had an opportunity to string-to-key parameter field when the KDC has had an opportunity to
provide it. provide it.
Sample test vectors are given in appendix B. Sample test vectors are given in appendix B.
skipping to change at page 3, line 48 skipping to change at page 3, line 44
done during encryption of messages of arbitrary sizes as is typically done during encryption of messages of arbitrary sizes as is typically
done in CBC mode with padding. Some errata for [RC5] are listed in done in CBC mode with padding. Some errata for [RC5] are listed in
appendix A, and are considered part of the cipher text stealing appendix A, and are considered part of the cipher text stealing
technique as used here. technique as used here.
Cipher text stealing, as defined in [RC5], assumes that more than one Cipher text stealing, as defined in [RC5], assumes that more than one
block of plain text is available. If exactly one block is to be block of plain text is available. If exactly one block is to be
encrypted, that block is simply encrypted with AES (also known as ECB encrypted, that block is simply encrypted with AES (also known as ECB
mode). Input of less than one block is padded at the end to one mode). Input of less than one block is padded at the end to one
block; the values of the padding bits are unspecified. block; the values of the padding bits are unspecified.
(Implementations may use all-zero padding, but protocols should not (Implementations MAY use all-zero padding, but protocols MUST NOT
rely on the result being deterministic. Implementations may use rely on the result being deterministic. Implementations MAY use
random padding, but protocols should not rely on the result not being random padding, but protocols MUST NOT rely on the result not being
deterministic. Note that in most cases, the Kerberos encryption deterministic. Note that in most cases, the Kerberos encryption
profile will add a random confounder independent of this padding.) profile will add a random confounder independent of this padding.)
For consistency, cipher text stealing is always used for the last two For consistency, cipher text stealing is always used for the last two
blocks of the data to be encrypted, as in [RC5]. If the data length blocks of the data to be encrypted, as in [RC5]. If the data length
is a multiple of the block size, this is equivalent to plain CBC mode is a multiple of the block size, this is equivalent to plain CBC mode
with the last two cipher text blocks swapped. with the last two cipher text blocks swapped.
A test vector is given in appendix B. A test vector is given in appendix B.
skipping to change at page 6, line 20 skipping to change at page 6, line 20
many powerful workstations at his disposal) must be balanced against many powerful workstations at his disposal) must be balanced against
the work factor imposed on the legitimate user (who may have a PDA or the work factor imposed on the legitimate user (who may have a PDA or
cell phone); the available computing power on either side increases cell phone); the available computing power on either side increases
as time goes on, as well. A better way to deal with the brute-force as time goes on, as well. A better way to deal with the brute-force
attack is through preauthentication mechanisms that provide better attack is through preauthentication mechanisms that provide better
protection of the user's long-term key. Use of such mechanisms is protection of the user's long-term key. Use of such mechanisms is
out of scope for this document. out of scope for this document.
If a site does wish to use this means of protection against a brute- If a site does wish to use this means of protection against a brute-
force attack, the iteration count should be chosen based on the force attack, the iteration count should be chosen based on the
facilities expected to be available to an attacker, and the amount of facilities available to both attacker and legitimate user, and the
work the attacker should be required to perform to acquire the key or amount of work the attacker should be required to perform to acquire
password. the key or password.
As an example: As an example:
The author's tests on a 2GHz Pentium 4 system indicated that in The author's tests on a 2GHz Pentium 4 system indicated that in
one second, nearly 90000 iterations could be done, producing a one second, nearly 90000 iterations could be done, producing a
256-bit key. This was using the SHA-1 assembly implementation 256-bit key. This was using the SHA-1 assembly implementation
from OpenSSL, and a pre-release version of the PBKDF2 code for from OpenSSL, and a pre-release version of the PBKDF2 code for
MIT's Kerberos package, on a single system. No attempt was made MIT's Kerberos package, on a single system. No attempt was made
to do multiple hashes in parallel, so we assume an attacker doing to do multiple hashes in parallel, so we assume an attacker doing
so can probably do at least 100000 iterations per second -- so can probably do at least 100000 iterations per second --
skipping to change at page 8, line 36 skipping to change at page 8, line 36
the reference. the reference.
10. Acknowledgements 10. Acknowledgements
Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
Leach, Marcus Watts, Larry Zhu and others for feedback on earlier Leach, Marcus Watts, Larry Zhu and others for feedback on earlier
versions of this document. versions of this document.
A. Errata for RFC 2040 section 8 A. Errata for RFC 2040 section 8
(Submitted to the RFC Editor by Bob Baldwin.) (Copied from the RFC Editor's errata web site on July 8, 2004.)
In Section 8, Page 18, first paragraph, second sentence should read: Reported By: Bob Baldwin; baldwin@plusfive.com
Date: Fri, 26 Mar 2004 06:49:02 -0800
This mode handles any length of plaintext longer than one block and In Section 8, Description of RC5-CTS, of the encryption method, it says:
produces ciphertext whose length matches the plaintext length.
In Section 8, page 19, step 6 of the decryption method should read: 1. Exclusive-or Pn-1 with the previous ciphertext
block, Cn-2, to create Xn-1.
6. Decrypt En and exclusive-or with Cn-2 to create Pn-1. For short It should say:
messages where Cn-2 does not exist, use the IV.
In section 8, page 19, step 1 of the encryption method (at the top of 1. Exclusive-or Pn-1 with the previous ciphertext
the page) should have the following sentence added at its end: block, Cn-2, to create Xn-1. For short messages where
Cn-2 does not exist, use IV.
For short messages where Cn-2 does not exist, use the IV. Reported By: Bob Baldwin; baldwin@plusfive.com
Date: Mon, 22 Mar 2004 20:26:40 -0800
In Section 8, first paragraph, second sentence says:
This mode handles any length of plaintext and produces ciphertext
whose length matches the plaintext length.
In Section 8, first paragraph, second sentence should read:
This mode handles any length of plaintext longer than one
block and produces ciphertext whose length matches the
plaintext length.
In Section 8, step 6 of the decryption method says:
6. Decrypt En to create Pn-1.
In Section 8, step 6 of the decryption method should read:
6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
For short messages where Cn-2 does not exist, use the IV.
B. Sample test vectors B. Sample test vectors
Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
included below. included below.
Iteration count = 1 Iteration count = 1
Pass phrase = "password" Pass phrase = "password"
Salt = "ATHENA.MIT.EDUraeburn" Salt = "ATHENA.MIT.EDUraeburn"
128-bit PBKDF2 output: 128-bit PBKDF2 output:
skipping to change at page 13, line 33 skipping to change at page 13, line 46
and Sons, New York, 1996. and Sons, New York, 1996.
[AES] National Institute of Standards and Technology, U.S. Department [AES] National Institute of Standards and Technology, U.S. Department
of Commerce, "Advanced Encryption Standard", Federal Information of Commerce, "Advanced Encryption Standard", Federal Information
Processing Standards Publication 197, Washington, DC, November 2001. Processing Standards Publication 197, Washington, DC, November 2001.
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002. Work in Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002. Work in
progress. progress.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
RC5-CTS Algorithms", RFC 2040, October 1996. RC5-CTS Algorithms", RFC 2040, October 1996.
[SHA1] National Institute of Standards and Technology, U.S. [SHA1] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", Federal Information Department of Commerce, "Secure Hash Standard", Federal Information
Processing Standards Publication 180-1, Washington, DC, April 1995. Processing Standards Publication 180-1, Washington, DC, April 1995.
skipping to change at page 15, line 17 skipping to change at page 15, line 35
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Notes to RFC Editor Notes to RFC Editor
Assuming this document goes through Last Call along with the Kerberos The reference entry for [KCRYPTO] lists the draft name, not the RFC
crypto framework draft, the reference entry for [KCRYPTO] will list number. This should be replaced with the RFC info when available.
the draft name, not the RFC number. This should be replaced with the
RFC info.
Remove Kerberos working group contact info from the Abstract; it's
right for the draft, but not the final RFC.
 End of changes. 16 change blocks. 
33 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/