draft-ietf-kitten-aes-cts-hmac-sha2-08.txt   draft-ietf-kitten-aes-cts-hmac-sha2-09.txt 
Network Working Group M. Jenkins Network Working Group M. Jenkins
Internet Draft National Security Agency Internet Draft National Security Agency
Intended Status: Informational M. Peck Intended Status: Informational M. Peck
Expires: June 11, 2016 The MITRE Corporation Expires: July 28, 2016 The MITRE Corporation
K. Burgin K. Burgin
December 9, 2015 January 25, 2016
AES Encryption with HMAC-SHA2 for Kerberos 5 AES Encryption with HMAC-SHA2 for Kerberos 5
draft-ietf-kitten-aes-cts-hmac-sha2-08 draft-ietf-kitten-aes-cts-hmac-sha2-09
Abstract Abstract
This document specifies two encryption types and two corresponding This document specifies two encryption types and two corresponding
checksum types for Kerberos 5. The new types use AES in CTS mode checksum types for Kerberos 5. The new types use AES in CTS mode
(CBC mode with ciphertext stealing) for confidentiality and HMAC with (CBC mode with ciphertext stealing) for confidentiality and HMAC with
a SHA-2 hash for integrity. a SHA-2 hash for integrity.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 11, 2016. This Internet-Draft will expire on July 28, 2016.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 36 skipping to change at page 4, line 36
When the encryption type is aes256-cts-hmac-sha384-192, then K1 is When the encryption type is aes256-cts-hmac-sha384-192, then K1 is
computed as follows: computed as follows:
K1 = HMAC-SHA-384(key, 0x00000001 | label | 0x00 | k) K1 = HMAC-SHA-384(key, 0x00000001 | label | 0x00 | k)
4. Key Generation from Pass Phrases 4. Key Generation from Pass Phrases
As defined below, the string-to-key function uses PBKDF2 [RFC2898] As defined below, the string-to-key function uses PBKDF2 [RFC2898]
and KDF-HMAC-SHA2 to derive the base-key from a passphrase and salt. and KDF-HMAC-SHA2 to derive the base-key from a passphrase and salt.
The string-to-key parameter string is four octets indicating an
unsigned number in big-endian order, consistent with [RFC3962],
except that the default is decimal 32768 if the parameter is not
specified.
To ensure that different long-term base-keys are used with different To ensure that different long-term base-keys are used with different
enctypes, we prepend the enctype name to the salt, separated by a enctypes, we prepend the enctype name to the salt, separated by a
null byte. The enctype-name is "aes128-cts-hmac-sha256-128" or null byte. The enctype-name is "aes128-cts-hmac-sha256-128" or
"aes256-cts-hmac-sha384-192" (without the quotes). "aes256-cts-hmac-sha384-192" (without the quotes).
The user's long-term base-key is derived as follows: The user's long-term base-key is derived as follows:
iter_count = string-to-key parameter (default is iter_count = string-to-key parameter, default is decimal 32768
decimal 32768 if not specified)
saltp = enctype-name | 0x00 | salt saltp = enctype-name | 0x00 | salt
tkey = random-to-key(PBKDF2(passphrase, saltp, tkey = random-to-key(PBKDF2(passphrase, saltp,
iter_count, keylength)) iter_count, keylength))
base-key = random-to-key(KDF-HMAC-SHA2(tkey, "kerberos", base-key = random-to-key(KDF-HMAC-SHA2(tkey, "kerberos",
keylength)) keylength))
where "kerberos" is the octet-string where "kerberos" is the octet-string
0x6B65726265726F73 0x6B65726265726F73
where the pseudorandom function used by PBKDF2 is HMAC-SHA-256 when where the pseudorandom function used by PBKDF2 is HMAC-SHA-256 when
the enctype is "aes128-cts-hmac-sha256-128" and HMAC-SHA-384 when the the enctype is "aes128-cts-hmac-sha256-128" and HMAC-SHA-384 when the
skipping to change at page 5, line 36 skipping to change at page 5, line 39
against the cipherstate concatenated with the ciphertext, and then against the cipherstate concatenated with the ciphertext, and then
decrypting the ciphertext if the HMAC is correct. Finally, the first decrypting the ciphertext if the HMAC is correct. Finally, the first
16 octets of the decryption output (the confounder) is discarded, and 16 octets of the decryption output (the confounder) is discarded, and
the remainder is returned as the plaintext decryption output. the remainder is returned as the plaintext decryption output.
The following parameters apply to the encryption types aes128-cts- The following parameters apply to the encryption types aes128-cts-
hmac-sha256-128 and aes256-cts-hmac-sha384-192. hmac-sha256-128 and aes256-cts-hmac-sha384-192.
protocol key format: as defined in Section 2. protocol key format: as defined in Section 2.
specific key structure: three protocol-format keys: { Kc, Ke, Ki }. specific key structure: three derived keys: { Kc, Ke, Ki }.
Kc: the checksum key, inputted into HMAC to provide the checksum Kc: the checksum key, inputted into HMAC to provide the checksum
mechanism defined in Section 6. mechanism defined in Section 6.
Ke: the encryption key, inputted into AES encryption and decryption Ke: the encryption key, inputted into AES encryption and decryption
as defined in "encryption function" and "decryption function" below. as defined in "encryption function" and "decryption function" below.
Ki: the integrity key, inputted into HMAC to provide authenticated Ki: the integrity key, inputted into HMAC to provide authenticated
encryption as defined in "encryption function" and "decryption encryption as defined in "encryption function" and "decryption
function" below. function" below.
skipping to change at page 8, line 18 skipping to change at page 8, line 22
TBD4 hmac-sha384-192-aes256 24 [this document] TBD4 hmac-sha384-192-aes256 24 [this document]
8. Security Considerations 8. Security Considerations
This specification requires implementations to generate random This specification requires implementations to generate random
values. The use of inadequate pseudo-random number generators values. The use of inadequate pseudo-random number generators
(PRNGs) can result in little or no security. The generation of (PRNGs) can result in little or no security. The generation of
quality random numbers is difficult. [RFC4086] offers random number quality random numbers is difficult. [RFC4086] offers random number
generation guidance. generation guidance.
This document specifies a mechanism for generating keys from pass This document specifies a mechanism for generating keys from
phrases or passwords. The salt and iteration count resist brute passphrases or passwords. The use of PBKDF2, a salt, and a large
force and dictionary attacks, however, it is still important to iteration count adds some resistance to off-line dictionary attacks
choose or generate strong passphrases. by passive eavesdroppers. Salting prevents rainbow table attacks,
while large iteration counts slow password guess attempts.
Nonetheless, it is important to choose strong passphrases. Use of
other Kerberos extensions that protect against off-line dictionary
attacks should also be considered.
NIST guidance in section 5.3 of [SP800-38A] requires CBC The NIST guidance in section 5.3 of [SP800-38A], requiring that CBC
initialization vectors be unpredictable. This specification does not initialization vectors be unpredictable, is satisfied by the use of a
formally comply with that guidance. However, the use of a confounder random confounder as the first block of plaintext. The confounder
as the first block of plaintext fills the cryptographic role fills the cryptographic role typically played by an initialization
typically played by an initialization vector. This approach was vector. This approach was chosen to align with other Kerberos
chosen to align with other Kerberos cryptosystem approaches. cryptosystem approaches.
8.1. Random Values in Salt Strings 8.1. Random Values in Salt Strings
NIST guidance in Section 5.1 of [SP800-132] requires that a portion NIST guidance in Section 5.1 of [SP800-132] requires at least 128
of the salt of at least 128 bits shall be randomly generated. Some bits of the salt to be randomly generated. The string-to-key function
known issues with including random values in Kerberos encryption type as defined in [RFC3961] requires the salt to be valid UTF-8 strings.
salt strings are: Not every 128-bit random string will be valid UTF-8, so a UTF-8
compatible encoding would be needed to encapsulate the random bits.
* The string-to-key function as defined in [RFC3961] requires the However, using a salt containing a random portion may have the
salt to be valid UTF-8 strings. Not every 128-bit random string
will be valid UTF-8.
Further, using a salt containing a random portion may have the
following issues with some implementations: following issues with some implementations:
* Cross-realm TGTs are typically managed by entering the same * Cross-realm TGTs are typically managed by entering the same
password at two KDCs to get the same keys. If each KDC uses a random password at two KDCs to get the same keys. If each KDC uses a
salt, they won't have the same keys. random salt, they won't have the same keys.
* Random salts may interfere with password history checking.
* ktutil's add_entry command assumes the default salt. * Random salts may interfere with password history checking.
8.2. Algorithm Rationale 8.2. Algorithm Rationale
This document has been written to be consistent with common This document has been written to be consistent with common
implementations of AES and SHA-2. The encryption and hash algorithm implementations of AES and SHA-2. The encryption and hash algorithm
sizes have been chosen to create a consistent level of protection, sizes have been chosen to create a consistent level of protection,
with consideration to implementation efficiencies. So, for instance, with consideration to implementation efficiencies. So, for instance,
SHA-384, which would normally be matched to AES-192, is instead SHA-384, which would normally be matched to AES-192, is instead
matched to AES-256 to leverage the fact that there are efficient matched to AES-256 to leverage the fact that there are efficient
hardware implementations of AES-256. Note that, as indicated by the hardware implementations of AES-256. Note that, as indicated by the
skipping to change at page 10, line 51 skipping to change at page 11, line 4
random 16 byte valid UTF-8 sequence | "ATHENA.MIT.EDUraeburn") random 16 byte valid UTF-8 sequence | "ATHENA.MIT.EDUraeburn")
256-bit base-key: 256-bit base-key:
45 BD 80 6D BF 6A 83 3A 9C FF C1 C9 45 89 A2 22 45 BD 80 6D BF 6A 83 3A 9C FF C1 C9 45 89 A2 22
36 7A 79 BC 21 C4 13 71 89 06 E9 F5 78 A7 84 67 36 7A 79 BC 21 C4 13 71 89 06 E9 F5 78 A7 84 67
Sample results for key derivation: Sample results for key derivation:
---------------------------------- ----------------------------------
enctype aes128-cts-hmac-sha256-128: enctype aes128-cts-hmac-sha256-128:
128-bit base-key: 128-bit base-key:
37 05 D9 60 80 C1 77 28 A0 E8 00 EA B6 E0 D2 3C
37 05 D9 60 80 C1 77 28 A0 E8 00 EA B6 E0 D2 3C
Kc value for key usage 2 (constant = 0x0000000299): Kc value for key usage 2 (constant = 0x0000000299):
B3 1A 01 8A 48 F5 47 76 F4 03 E9 A3 96 32 5D C3 B3 1A 01 8A 48 F5 47 76 F4 03 E9 A3 96 32 5D C3
Ke value for key usage 2 (constant = 0x00000002AA): Ke value for key usage 2 (constant = 0x00000002AA):
9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E 9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E
Ki value for key usage 2 (constant = 0x0000000255): Ki value for key usage 2 (constant = 0x0000000255):
9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C 9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C
enctype aes256-cts-hmac-sha384-192: enctype aes256-cts-hmac-sha384-192:
256-bit base-key: 256-bit base-key:
6D 40 4D 37 FA F7 9F 9D F0 D3 35 68 D3 20 66 98 6D 40 4D 37 FA F7 9F 9D F0 D3 35 68 D3 20 66 98
skipping to change at page 11, line 52 skipping to change at page 12, line 4
AES Output: AES Output:
EF 85 FB 89 0B B8 47 2F 4D AB 20 39 4D CA 78 1D EF 85 FB 89 0B B8 47 2F 4D AB 20 39 4D CA 78 1D
Truncated HMAC Output: Truncated HMAC Output:
AD 87 7E DA 39 D5 0C 87 0C 0D 5A 0A 8E 48 C7 18 AD 87 7E DA 39 D5 0C 87 0C 0D 5A 0A 8E 48 C7 18
Ciphertext (AES Output | HMAC Output): Ciphertext (AES Output | HMAC Output):
EF 85 FB 89 0B B8 47 2F 4D AB 20 39 4D CA 78 1D EF 85 FB 89 0B B8 47 2F 4D AB 20 39 4D CA 78 1D
AD 87 7E DA 39 D5 0C 87 0C 0D 5A 0A 8E 48 C7 18 AD 87 7E DA 39 D5 0C 87 0C 0D 5A 0A 8E 48 C7 18
Plaintext: (length less than block size) Plaintext: (length less than block size)
00 01 02 03 04 05 00 01 02 03 04 05
Confounder:
Confounder:
7B CA 28 5E 2F D4 13 0F B5 5B 1A 5C 83 BC 5B 24 7B CA 28 5E 2F D4 13 0F B5 5B 1A 5C 83 BC 5B 24
128-bit AES key (Ke): 128-bit AES key (Ke):
9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E 9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E
128-bit HMAC key (Ki): 128-bit HMAC key (Ki):
9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C 9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C
AES Output: AES Output:
84 D7 F3 07 54 ED 98 7B AB 0B F3 50 6B EB 09 CF 84 D7 F3 07 54 ED 98 7B AB 0B F3 50 6B EB 09 CF
B5 54 02 CE F7 E6 B5 54 02 CE F7 E6
Truncated HMAC Output: Truncated HMAC Output:
87 7C E9 9E 24 7E 52 D1 6E D4 42 1D FD F8 97 6C 87 7C E9 9E 24 7E 52 D1 6E D4 42 1D FD F8 97 6C
skipping to change at page 12, line 52 skipping to change at page 13, line 4
A7 A4 E2 9A 47 28 CE 10 66 4F B6 4E 49 AD 3F AC A7 A4 E2 9A 47 28 CE 10 66 4F B6 4E 49 AD 3F AC
128-bit AES key (Ke): 128-bit AES key (Ke):
9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E 9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E
128-bit HMAC key (Ki): 128-bit HMAC key (Ki):
9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C 9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C
AES Output: AES Output:
72 0F 73 B1 8D 98 59 CD 6C CB 43 46 11 5C D3 36 72 0F 73 B1 8D 98 59 CD 6C CB 43 46 11 5C D3 36
C7 0F 58 ED C0 C4 43 7C 55 73 54 4C 31 C8 13 BC C7 0F 58 ED C0 C4 43 7C 55 73 54 4C 31 C8 13 BC
E1 E6 D0 72 C1 E1 E6 D0 72 C1
Truncated HMAC Output: Truncated HMAC Output:
86 B3 9A 41 3C 2F 92 CA 9B 83 34 A2 87 FF CB FC
86 B3 9A 41 3C 2F 92 CA 9B 83 34 A2 87 FF CB FC
Ciphertext: Ciphertext:
72 0F 73 B1 8D 98 59 CD 6C CB 43 46 11 5C D3 36 72 0F 73 B1 8D 98 59 CD 6C CB 43 46 11 5C D3 36
C7 0F 58 ED C0 C4 43 7C 55 73 54 4C 31 C8 13 BC C7 0F 58 ED C0 C4 43 7C 55 73 54 4C 31 C8 13 BC
E1 E6 D0 72 C1 86 B3 9A 41 3C 2F 92 CA 9B 83 34 E1 E6 D0 72 C1 86 B3 9A 41 3C 2F 92 CA 9B 83 34
A2 87 FF CB FC A2 87 FF CB FC
The following test vectors are for enctype The following test vectors are for enctype
aes256-cts-hmac-sha384-192: aes256-cts-hmac-sha384-192:
Plaintext: (empty) Plaintext: (empty)
 End of changes. 19 change blocks. 
37 lines changed or deleted 38 lines changed or added

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