 1/draftietfkittenaesctshmacsha209.txt 20160705 11:16:01.903191633 0700
+++ 2/draftietfkittenaesctshmacsha210.txt 20160705 11:16:01.935192436 0700
@@ 1,20 +1,20 @@
Network Working Group M. Jenkins
Internet Draft National Security Agency
Intended Status: Informational M. Peck
Expires: July 28, 2016 The MITRE Corporation
+Expires: January 6, 2017 The MITRE Corporation
K. Burgin
 January 25, 2016
+ July 5, 2016
AES Encryption with HMACSHA2 for Kerberos 5
 draftietfkittenaesctshmacsha209
+ draftietfkittenaesctshmacsha210
Abstract
This document specifies two encryption types and two corresponding
checksum types for Kerberos 5. The new types use AES in CTS mode
(CBC mode with ciphertext stealing) for confidentiality and HMAC with
a SHA2 hash for integrity.
Status of this Memo
@@ 24,21 +24,21 @@
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
Drafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts 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 InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on July 28, 2016.
+ This InternetDraft will expire on January 6, 2017.
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
@@ 49,49 +49,50 @@
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Key Representation . . . . . . . . . . . . . . . . . 3
3. Key Derivation Function . . . . . . . . . . . . . . . . . . . 3
4. Key Generation from Pass Phrases . . . . . . . . . . . . . . . 4
5. Kerberos Algorithm Protocol Parameters . . . . . . . . . . . . 5
6. Checksum Parameters . . . . . . . . . . . . . . . . . . . . . 7
 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
 8.1. Random Values in Salt Strings . . . . . . . . . . . . . . 8
+ 8.1. Random Values in Salt Strings . . . . . . . . . . . . . . 9
8.2. Algorithm Rationale . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
 10.2. Informative References . . . . . . . . . . . . . . . . . 9
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This document defines two encryption types and two corresponding
checksum types for Kerberos 5 using AES with 128bit or 256bit keys.
To avoid ciphertext expansion, we use a variation of the CBCCS3 mode
defined in [SP80038A+], also referred to as ciphertext stealing or
CTS mode. The new types conform to the framework specified in
[RFC3961], but do not use the simplified profile.
The encryption and checksum types defined in this document are
intended to support environments that desire to use SHA256 or SHA
 384 as the hash algorithm. Differences between the encryption and
 checksum types defined in this document and the preexisting Kerberos
 AES encryption and checksum types specified in [RFC3962] are:
+ 384 (defined in [FIPS180]) as the hash algorithm. Differences
+ between the encryption and checksum types defined in this document
+ and the preexisting Kerberos AES encryption and checksum types
+ specified in [RFC3962] are:
* The pseudorandom function used by PBKDF2 is HMACSHA256 or HMAC
 SHA384.
+ SHA384 (HMAC is defined in [RFC2104]).
* A key derivation function from [SP800108] using the SHA256 or
SHA384 hash algorithm is used to produce keys for encryption,
integrity protection, and checksum operations.
* The HMAC is calculated over the cipherstate concatenated with the
AES output, instead of being calculated over the confounder and
plaintext. This allows the message receiver to verify the
integrity of the message before decrypting the message.
@@ 103,89 +104,110 @@
The AES key space is dense, so we can use random or pseudorandom
octet strings directly as keys. The byte representation for the key
is described in [FIPS197], where the first bit of the bit string is
the high bit of the first byte of the byte string (octet string).
3. Key Derivation Function
We use a key derivation function from Section 5.1 of [SP800108]
which uses the HMAC algorithm as the PRF.
 KDFHMACSHA2(key, label, k) = ktruncate(K1)
+ function KDFHMACSHA2(key, label, [context,] k):
+ ktruncate(K1)
+
+ where the value of K1 is computed as below.
key: The source of entropy from which subsequent keys are derived
(this is known as Ki in [SP800108]).
label: An octet string describing the intended usage of the derived
key.
+ context: This parameter is optional. An octet string containing the
+ information related to the derived keying material. It may include
+ identities of parties who are deriving and/or using the derived key
+ material and, optionally, a nonce known by the parties who derive the
+ keys.
+
k: Length in bits of the key to be outputted, expressed in bigendian
 binary representation in 4 bytes (this is known as L in [SP800108]).
 (e.g. k = 128 is represented as 0x00000080,
 k = 192 as 0x000000C0, k = 256 as 0x00000100,
 k = 384 as 0x00000180)
+ binary representation in 4 bytes (this is called L in [SP800108]).
+ Specifically, k=128 is represented as 0x00000080, 192 as 0x000000C0,
+ 256 as 0x00000100, and 384 as 0x00000180.
When the encryption type is aes128ctshmacsha256128, k must be no
greater than 256. When the encryption type is aes256ctshmacsha384
192, k must be no greater than 384.
 The ktruncate function is defined in [RFC3961], Section 5.1.
+ The ktruncate function is defined in [RFC3961], Section 5.1. It
+ returns the 'k' leftmost bits of the bitstring input.
In all computations in this document,  indicates concatenation.
When the encryption type is aes128ctshmacsha256128, then K1 is
computed as follows:
+ If the context parameter is not present:
K1 = HMACSHA256(key, 0x00000001  label  0x00  k)
+ If the context parameter is present:
+ K1 = HMACSHA256(key, 0x00000001  label  0x00  context  k)
+
When the encryption type is aes256ctshmacsha384192, then K1 is
computed as follows:
+ If the context parameter is not present:
K1 = HMACSHA384(key, 0x00000001  label  0x00  k)
4. Key Generation from Pass Phrases
+ If the context parameter is present:
+ K1 = HMACSHA384(key, 0x00000001  label  0x00  context  k)
+
+ In the definitions of K1 above, '0x00000001' is the i parameter (the
+ iteration counter) from Section 5.1 of [SP800108].
+4. Key Generation from Pass Phrases
As defined below, the stringtokey function uses PBKDF2 [RFC2898]
and KDFHMACSHA2 to derive the basekey from a passphrase and salt.
The stringtokey parameter string is four octets indicating an
unsigned number in bigendian order, consistent with [RFC3962],
except that the default is decimal 32768 if the parameter is not
specified.
To ensure that different longterm basekeys are used with different
enctypes, we prepend the enctype name to the salt, separated by a
null byte. The enctypename is "aes128ctshmacsha256128" or
"aes256ctshmacsha384192" (without the quotes).
The user's longterm basekey is derived as follows:
iter_count = stringtokey parameter, default is decimal 32768
saltp = enctypename  0x00  salt
tkey = randomtokey(PBKDF2(passphrase, saltp,
iter_count, keylength))
basekey = randomtokey(KDFHMACSHA2(tkey, "kerberos",
keylength))
 where "kerberos" is the octetstring
 0x6B65726265726F73
 where the pseudorandom function used by PBKDF2 is HMACSHA256 when
 the enctype is "aes128ctshmacsha256128" and HMACSHA384 when the
 enctype is "aes256ctshmacsha384192", the value for keylength is
 the AES key length (128 or 256 bits), and the algorithm KDFHMACSHA2
 is defined in Section 3.
+ where "kerberos" is the octetstring 0x6B65726265726F73.
+
+ where PBKDF2 is the function of that name from RFC 2898, the
+ pseudorandom function used by PBKDF2 is HMACSHA256 when the enctype
+ is "aes128ctshmacsha256128" and HMACSHA384 when the enctype is
+ "aes256ctshmacsha384192", the value for keylength is the AES key
+ length (128 or 256 bits), and the algorithm KDFHMACSHA2 is defined
+ in Section 3.
5. Kerberos Algorithm Protocol Parameters
 The cipherstate is used as the formal initialization vector (IV)
 input into CBCCS3. The plaintext is prepended with a 16octet
 random nonce generated by the message originator, known as a
 confounder.
+ The RFC 3961 cipher state that maintains cryptographic state across
+ different encryption operations using the same key is used as the
+ formal initialization vector (IV) input into CBCCS3. The plaintext
+ is prepended with a 16octet random nonce generated by the message
+ originator, known as a confounder.
The ciphertext is a concatenation of the output of AES in CBCCS3
mode and the HMAC of the cipherstate concatenated with the AES
output. The HMAC is computed using either SHA256 or SHA384
depending on the encryption type. The output of HMACSHA256 is
truncated to 128 bits and the output of HMACSHA384 is truncated to
192 bits. Sample test vectors are given in Appendix A.
Decryption is performed by removing the HMAC, verifying the HMAC
against the cipherstate concatenated with the ciphertext, and then
@@ 226,22 +248,23 @@
If the enctype is aes128ctshmacsha256128:
Kc = KDFHMACSHA2(basekey, usage  0x99, 128)
Ke = KDFHMACSHA2(basekey, usage  0xAA, 128)
Ki = KDFHMACSHA2(basekey, usage  0x55, 128)
If the enctype is aes256ctshmacsha384192:
Kc = KDFHMACSHA2(basekey, usage  0x99, 192)
Ke = KDFHMACSHA2(basekey, usage  0xAA, 256)
Ki = KDFHMACSHA2(basekey, usage  0x55, 192)
 cipherstate: a 128bit CBC initialization vector derived from
 the ciphertext.
+ cipher state: a 128bit CBC initialization vector derived from a
+ previous (if any) ciphertext using the same encryption key, as
+ specified below.
initial cipherstate: all bits zero.
encryption function: as follows, where E() is AES encryption in
CBCCS3 mode, and h is the size of truncated HMAC (128 bits or
192 bits as described above).
N = random nonce of length 128 bits (the AES block size)
IV = cipherstate
C = E(Ke, N  plaintext, IV)
@@ 251,50 +274,53 @@
Steps to compute the 128bit cipherstate:
L = length of C in bits
portion C into 128bit blocks, placing any remainder
of less than 128 bits into a final block
if L == 128: cipherstate = C
else if L mod 128 > 0: cipherstate = last full (128bit)
block of C (the
nexttolast block)
else if L mod 128 == 0: cipherstate = nexttolast block
of C
+ (note that L will never be less than 128 because of the
+ presence of N in the encryption input)
decryption function: as follows, where D() is AES decryption in
CBCCS3 mode, and h is the size of truncated HMAC.
 (C, H) = ciphertext
+ (C, H) = ciphertext (Note: H is the last h bits of the ciphertext)
IV = cipherstate
if H != HMAC(Ki, IV  C)[1..h]
stop, report error
(N, P) = D(Ke, C, IV)
Note: N is set to the first block of the decryption output,
P is set to the rest of the output.
cipherstate = same as described above in encryption function
pseudorandom function:
If the enctype is aes128ctshmacsha256128:
 PRF = KDFHMACSHA2(basekey, "prf"  octetstring, 256)
+ PRF = KDFHMACSHA2(inputkey, "prf", octetstring, 256)
If the enctype is aes256ctshmacsha384192:
 PRF = KDFHMACSHA2(basekey, "prf"  octetstring, 384)
+ PRF = KDFHMACSHA2(inputkey, "prf", octetstring, 384)
where "prf" is the octetstring 0x707266
6. Checksum Parameters
The following parameters apply to the checksum types hmacsha256128
aes128 and hmacsha384192aes256, which are the associated checksums
for aes128ctshmacsha256128 and aes256ctshmacsha384192,
respectively.
 associated cryptosystem: AES128CTS or AES256CTS as appropriate.
+ associated cryptosystem: aes128ctshmacsha256128 or aes256cts
+ hmacsha384192 as appropriate.
get_mic: HMAC(Kc, message)[1..h].
where h is 128 bits for checksum type hmacsha256128aes128
and 192 bits for checksum type hmacsha384192aes256
verify_mic: get_mic and compare.
7. IANA Considerations
IANA is requested to assign:
@@ 343,23 +369,23 @@
8.1. Random Values in Salt Strings
NIST guidance in Section 5.1 of [SP800132] requires at least 128
bits of the salt to be randomly generated. The stringtokey function
as defined in [RFC3961] requires the salt to be valid UTF8 strings.
Not every 128bit random string will be valid UTF8, so a UTF8
compatible encoding would be needed to encapsulate the random bits.
However, using a salt containing a random portion may have the
following issues with some implementations:
 * Crossrealm TGTs are typically managed by entering the same
 password at two KDCs to get the same keys. If each KDC uses a
 random salt, they won't have the same keys.
+ * Crossrealm krbtgt keys are typically managed by entering the
+ same password at two KDCs to get the same keys. If each KDC uses
+ a random salt, they won't have the same keys.
* Random salts may interfere with password history checking.
8.2. Algorithm Rationale
This document has been written to be consistent with common
implementations of AES and SHA2. The encryption and hash algorithm
sizes have been chosen to create a consistent level of protection,
with consideration to implementation efficiencies. So, for instance,
SHA384, which would normally be matched to AES192, is instead
@@ 368,32 +394,37 @@
enctype name "aes256ctshmacsha384192", the truncation of the
HMACSHA384 output to 192bits results in an overall 192bit level
of security.
9. Acknowledgements
Kelley Burgin was employed at the National Security Agency during
much of the work on this document.
10. References

10.1. Normative References
+ [RFC2104] Krawczyk, H. et al., "HMAC: KeyedHashing for Message
+ Authentication", RFC 2104, February 1997.
+
[RFC2898] Kaliski, B., "PKCS #5: PasswordBased Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
+ [FIPS180] National Institute of Standards and Technology, "Secure
+ Hash Standard", FIPS PUB 1804, August 2015.
+
[FIPS197] National Institute of Standards and Technology,
"Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001.
[SP80038A+] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Three Variants of Ciphertext Stealing for CBC Mode",
NIST Special Publication 80038A Addendum, October 2010.
[SP800108] National Institute of Standards and Technology,
@@ 444,40 +474,40 @@
random 16 byte valid UTF8 sequence  "ATHENA.MIT.EDUraeburn")
256bit basekey:
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
Sample results for key derivation:

enctype aes128ctshmacsha256128:
128bit basekey:

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 (label = 0x0000000299):
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 (label = 0x00000002AA):
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 (label = 0x0000000255):
9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C
enctype aes256ctshmacsha384192:
256bit basekey:
6D 40 4D 37 FA F7 9F 9D F0 D3 35 68 D3 20 66 98
00 EB 48 36 47 2E A8 A0 26 D1 6B 71 82 46 0C 52
 Kc value for key usage 2 (constant = 0x0000000299):
+ Kc value for key usage 2 (label = 0x0000000299):
EF 57 18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 C4
BA 41 F2 8F AF 69 E7 3D
 Ke value for key usage 2 (constant = 0x00000002AA):
+ Ke value for key usage 2 (label = 0x00000002AA):
+
56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7
A5 EB 1C 82 51 60 C3 83 12 98 0C 44 2E 5C 7E 49
 Ki value for key usage 2 (constant = 0x0000000255):
+ Ki value for key usage 2 (label = 0x0000000255):
69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6
22 C4 D0 0F FC 23 ED 1F
Sample encryptions (all using the default cipher state):

These sample encryptions use the above sample key
derivation results, including use of the same
basekey and key usage values.
The following test vectors are for
@@ 664,45 +694,44 @@
Checksum type: hmacsha384192aes256
192bit HMAC key (Kc):
EF 57 18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 C4
BA 41 F2 8F AF 69 E7 3D
Plaintext:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14
Checksum:
45 EE 79 15 67 EE FC A3 7F 4A C1 E0 22 2D E8 0D
43 C3 BF A0 66 99 67 2A

Sample pseudorandom function (PRF) invocations:

PRF input octetstring: "test" (0x74657374)
enctype aes128ctshmacsha256128:
 basekey value / HMACSHA256 key:
+ inputkey value / HMACSHA256 key:
37 05 D9 60 80 C1 77 28 A0 E8 00 EA B6 E0 D2 3C
HMACSHA256 input message:
 00 00 00 01 70 72 66 74 65 73 74 00 00 00 01 00
+ 00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 00
PRF output:
 14 11 15 B0 A6 CB 9A 1D CB B4 C7 E2 5B 43 32 22
 52 DE 58 11 21 85 C5 DC F5 12 5E 7B 81 54 8D 39
+ 9D 18 86 16 F6 38 52 FE 86 91 5B B8 40 B4 A8 86
+ FF 3E 6B B0 F8 19 B4 9B 89 33 93 D3 93 85 42 95
enctype aes256ctshmacsha384192:
 basekey value / HMACSHA384 key:
+ inputkey value / HMACSHA384 key:
6D 40 4D 37 FA F7 9F 9D F0 D3 35 68 D3 20 66 98
00 EB 48 36 47 2E A8 A0 26 D1 6B 71 82 46 0C 52
HMACSHA384 input message:
 00 00 00 01 70 72 66 74 65 73 74 00 00 00 01 80
+ 00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 80
PRF output:
 31 0A 4B 5C D2 90 F7 04 33 B2 A1 A1 D0 93 FD F7
 8C 6C 9D AE 5C AC D3 A7 BD 45 CB 67 44 41 99 43
 0D 36 19 06 44 E8 A2 16 66 43 AE AD E9 63 87 52
+ 98 01 F6 9A 36 8C 2B F6 75 E5 95 21 E1 77 D9 A0
+ 7F 67 EF E1 CF DE 8D 3C 8D 6F 6A 02 56 E3 B1 7D
+ B3 C1 B6 2A D1 B8 55 33 60 D1 73 67 EB 15 14 D2
Authors' Addresses
Michael J. Jenkins
National Security Agency
EMail: mjjenki@tycho.ncsc.mil
Michael A. Peck
The MITRE Corporation