draft-ietf-kitten-aes-cts-hmac-sha2-11.txt | rfc8009.txt | |||
---|---|---|---|---|

Network Working Group M. Jenkins | Internet Engineering Task Force (IETF) M. Jenkins | |||

Internet Draft National Security Agency | Request for Comments: 8009 National Security Agency | |||

Intended Status: Informational M. Peck | Category: Informational M. Peck | |||

Expires: February 27, 2017 The MITRE Corporation | ISSN: 2070-1721 The MITRE Corporation | |||

K. Burgin | K. Burgin | |||

August 26, 2016 | October 2016 | |||

AES Encryption with HMAC-SHA2 for Kerberos 5 | AES Encryption with HMAC-SHA2 for Kerberos 5 | |||

draft-ietf-kitten-aes-cts-hmac-sha2-11 | ||||

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 | |||

This Internet-Draft is submitted in full conformance with the | ||||

provisions of BCP 78 and BCP 79. | ||||

Internet-Drafts are working documents of the Internet Engineering | This document is not an Internet Standards Track specification; it is | |||

Task Force (IETF). Note that other groups may also distribute | published for informational purposes. | |||

working documents as Internet-Drafts. The list of current Internet- | ||||

Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||

Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||

and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||

time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||

material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||

approved by the IESG are a candidate for any level of Internet | ||||

Standard; see Section 2 of RFC 7841. | ||||

This Internet-Draft will expire on February 27, 2017. | Information about the current status of this document, any errata, | |||

and how to provide feedback on it may be obtained at | ||||

http://www.rfc-editor.org/info/rfc8009. | ||||

Copyright and License Notice | Copyright Notice | |||

Copyright (c) 2016 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 | |||

described in the Simplified BSD License. | described in the Simplified BSD License. | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||

2. Protocol Key Representation . . . . . . . . . . . . . . . . . 3 | 2. Protocol Key Representation . . . . . . . . . . . . . . . . . 3 | |||

3. Key Derivation Function . . . . . . . . . . . . . . . . . . . 3 | 3. Key Derivation Function . . . . . . . . . . . . . . . . . . . 3 | |||

4. Key Generation from Pass Phrases . . . . . . . . . . . . . . . 5 | 4. Key Generation from Pass Phrases . . . . . . . . . . . . . . . 4 | |||

5. Kerberos Algorithm Protocol Parameters . . . . . . . . . . . . 5 | 5. Kerberos Algorithm Protocol Parameters . . . . . . . . . . . . 5 | |||

6. Checksum Parameters . . . . . . . . . . . . . . . . . . . . . 8 | 6. Checksum Parameters . . . . . . . . . . . . . . . . . . . . . 7 | |||

7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||

8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||

8.1. Random Values in Salt Strings . . . . . . . . . . . . . . 9 | 8.1. Random Values in Salt Strings . . . . . . . . . . . . . . 9 | |||

8.2. Algorithm Rationale . . . . . . . . . . . . . . . . . . . 9 | 8.2. Algorithm Rationale . . . . . . . . . . . . . . . . . . . 9 | |||

9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||

10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | |||

10.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 | |||

10.2. Informative References . . . . . . . . . . . . . . . . . 10 | Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 12 | |||

Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 11 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||

1. Introduction | 1. Introduction | |||

This document defines two encryption types and two corresponding | This document defines two encryption types and two corresponding | |||

checksum types for Kerberos 5 using AES with 128-bit or 256-bit keys. | checksum types for Kerberos 5 using AES with 128-bit or 256-bit keys. | |||

To avoid ciphertext expansion, we use a variation of the CBC-CS3 mode | To avoid ciphertext expansion, we use a variation of the CBC-CS3 mode | |||

defined in [SP800-38A+], also referred to as ciphertext stealing or | defined in [SP800-38A+], also referred to as ciphertext stealing or | |||

CTS mode. The new types conform to the framework specified in | CTS mode. The new types conform to the framework specified in | |||

[RFC3961], but do not use the simplified profile, as the simplified | [RFC3961], but do not use the simplified profile, as the simplified | |||

profile is not compliant with modern cryptographic best practices | profile is not compliant with modern cryptographic best practices | |||

such as calculating MACs over ciphertext rather than plaintext. | such as calculating Message Authentication Codes (MACs) over | |||

ciphertext rather than plaintext. | ||||

The encryption and checksum types defined in this document are | The encryption and checksum types defined in this document are | |||

intended to support environments that desire to use SHA-256 or SHA- | intended to support environments that desire to use SHA-256 or | |||

384 (defined in [FIPS180]) as the hash algorithm. Differences | SHA-384 (defined in [FIPS180]) as the hash algorithm. Differences | |||

between the encryption and checksum types defined in this document | between the encryption and checksum types defined in this document | |||

and the pre-existing Kerberos AES encryption and checksum types | and the pre-existing Kerberos AES encryption and checksum types | |||

specified in [RFC3962] are: | specified in [RFC3962] are: | |||

* The pseudorandom function used by PBKDF2 is HMAC-SHA-256 or HMAC- | * The pseudorandom function (PRF) used by PBKDF2 is HMAC-SHA-256 or | |||

SHA-384 (HMAC is defined in [RFC2104]). | HMAC-SHA-384. (HMAC is defined in [RFC2104].) | |||

* A key derivation function from [SP800-108] using the SHA-256 or | * A key derivation function from [SP800-108] using the SHA-256 or | |||

SHA-384 hash algorithm is used to produce keys for encryption, | SHA-384 hash algorithm is used to produce keys for encryption, | |||

integrity protection, and checksum operations. | integrity protection, and checksum operations. | |||

* The HMAC is calculated over the cipherstate concatenated with the | * The HMAC is calculated over the cipher state concatenated with the | |||

AES output, instead of being calculated over the confounder and | AES output, instead of being calculated over the confounder and | |||

plaintext. This allows the message receiver to verify the | plaintext. This allows the message receiver to verify the | |||

integrity of the message before decrypting the message. | integrity of the message before decrypting the message. | |||

* The HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm for | * The HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm for | |||

integrity protection and checksum operations. | integrity protection and checksum operations. | |||

2. Protocol Key Representation | 2. Protocol Key Representation | |||

The AES key space is dense, so we can use random or pseudorandom | The AES key space is dense, so we can use random or pseudorandom | |||

octet strings directly as keys. The byte representation for the key | octet strings directly as keys. The byte representation for the key | |||

is described in [FIPS197], where the first bit of the bit string is | 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). | the high bit of the first byte of the byte string (octet string). | |||

3. Key Derivation Function | 3. Key Derivation Function | |||

We use a key derivation function from Section 5.1 of [SP800-108] | We use a key derivation function from Section 5.1 of [SP800-108], | |||

which uses the HMAC algorithm as the PRF. | which uses the HMAC algorithm as the PRF. | |||

function KDF-HMAC-SHA2(key, label, [context,] k): | function KDF-HMAC-SHA2(key, label, [context,] k): | |||

k-truncate(K1) | k-truncate(K1) | |||

where the value of K1 is computed as below. | where the value of K1 is computed as below. | |||

key: The source of entropy from which subsequent keys are derived | key: The source of entropy from which subsequent keys are derived. | |||

(this is known as Ki in [SP800-108]). | (This is known as "Ki" in [SP800-108].) | |||

label: An octet string describing the intended usage of the derived | label: An octet string describing the intended usage of the derived | |||

key. | key. | |||

context: This parameter is optional. An octet string containing the | context: This parameter is optional. An octet string containing the | |||

information related to the derived keying material. This | information related to the derived keying material. This | |||

specification does not dictate a specific format for the context | specification does not dictate a specific format for the context | |||

field. The context field is only used by the pseudo-random function | field. The context field is only used by the pseudorandom function | |||

defined in section 5, where it is set to the pseudo-random function's | defined in Section 5, where it is set to the pseudorandom function's | |||

octet-string input parameter. The content of the octet-string input | octet-string input parameter. The content of the octet-string input | |||

parameter is defined by the application that uses it. | parameter is defined by the application that uses it. | |||

k: Length in bits of the key to be outputted, expressed in big-endian | k: Length in bits of the key to be outputted, expressed in big-endian | |||

binary representation in 4 bytes (this is called L in [SP800-108]). | binary representation in 4 bytes. (This is called "L" in | |||

Specifically, k=128 is represented as 0x00000080, 192 as 0x000000C0, | [SP800-108].) Specifically, k=128 is represented as 0x00000080, 192 | |||

256 as 0x00000100, and 384 as 0x00000180. | as 0x000000C0, 256 as 0x00000100, and 384 as 0x00000180. | |||

When the encryption type is aes128-cts-hmac-sha256-128, k must be no | When the encryption type is aes128-cts-hmac-sha256-128, k must be no | |||

greater than 256 bits. When the encryption type is aes256-cts-hmac- | greater than 256 bits. When the encryption type is | |||

sha384-192, k must be no greater than 384 bits. | aes256-cts-hmac-sha384-192, k must be no greater than 384 bits. | |||

The k-truncate function is defined in [RFC3961], Section 5.1. It | The k-truncate function is defined in Section 5.1 of [RFC3961]. It | |||

returns the 'k' leftmost bits of the bitstring input. | returns the 'k' leftmost bits of the bit-string input. | |||

In all computations in this document, | indicates concatenation. | In all computations in this document, "|" indicates concatenation. | |||

When the encryption type is aes128-cts-hmac-sha256-128, then K1 is | When the encryption type is aes128-cts-hmac-sha256-128, then K1 is | |||

computed as follows: | computed as follows: | |||

If the context parameter is not present: | If the context parameter is not present: | |||

K1 = HMAC-SHA-256(key, 0x00000001 | label | 0x00 | k) | K1 = HMAC-SHA-256(key, 0x00000001 | label | 0x00 | k) | |||

If the context parameter is present: | If the context parameter is present: | |||

K1 = HMAC-SHA-256(key, 0x00000001 | label | 0x00 | context | k) | K1 = HMAC-SHA-256(key, 0x00000001 | label | 0x00 | context | k) | |||

skipping to change at page 5, line 12 ¶ | skipping to change at page 4, line 35 ¶ | |||

If the context parameter is present: | If the context parameter is present: | |||

K1 = HMAC-SHA-384(key, 0x00000001 | label | 0x00 | context | k) | K1 = HMAC-SHA-384(key, 0x00000001 | label | 0x00 | context | k) | |||

In the definitions of K1 above, '0x00000001' is the i parameter (the | In the definitions of K1 above, '0x00000001' is the i parameter (the | |||

iteration counter) from Section 5.1 of [SP800-108]. | iteration counter) from Section 5.1 of [SP800-108]. | |||

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 | The string-to-key parameter string is 4 octets indicating an unsigned | |||

unsigned number in big-endian order, consistent with [RFC3962], | number in big-endian order, consistent with [RFC3962], except that | |||

except that the default is decimal 32768 if the parameter is not | the default is decimal 32768 if the parameter is not specified. | |||

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 decimal 32768 | iter_count = string-to-key parameter, default is decimal 32768 | |||

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 0x6B65726265726F73. | where "kerberos" is the octet-string 0x6B65726265726F73. | |||

where PBKDF2 is the function of that name from RFC 2898, the | where PBKDF2 is the function of that name from RFC 2898, the | |||

pseudorandom function used by PBKDF2 is HMAC-SHA-256 when the enctype | pseudorandom function used by PBKDF2 is HMAC-SHA-256 when the enctype | |||

is "aes128-cts-hmac-sha256-128" and HMAC-SHA-384 when the enctype is | is "aes128-cts-hmac-sha256-128" and HMAC-SHA-384 when the enctype is | |||

"aes256-cts-hmac-sha384-192", the value for keylength is the AES key | "aes256-cts-hmac-sha384-192", the value for keylength is the AES key | |||

length (128 or 256 bits), and the algorithm KDF-HMAC-SHA2 is defined | length (128 or 256 bits), and the algorithm KDF-HMAC-SHA2 is defined | |||

in Section 3. | in Section 3. | |||

5. Kerberos Algorithm Protocol Parameters | 5. Kerberos Algorithm Protocol Parameters | |||

The RFC 3961 cipher state that maintains cryptographic state across | The cipher state defined in RFC 3961 that maintains cryptographic | |||

different encryption operations using the same key is used as the | state across different encryption operations using the same key is | |||

formal initialization vector (IV) input into CBC-CS3. The plaintext | used as the formal initialization vector (IV) input into CBC-CS3. | |||

is prepended with a 16-octet random value generated by the message | The plaintext is prepended with a 16-octet random value generated by | |||

originator, known as a confounder. | the message originator, known as a confounder. | |||

The ciphertext is a concatenation of the output of AES in CBC-CS3 | The ciphertext is a concatenation of the output of AES in CBC-CS3 | |||

mode and the HMAC of the cipher state concatenated with the AES | mode and the HMAC of the cipher state concatenated with the AES | |||

output. The HMAC is computed using either SHA-256 or SHA-384 | output. The HMAC is computed using either SHA-256 or SHA-384 | |||

depending on the encryption type. The output of HMAC-SHA-256 is | depending on the encryption type. The output of HMAC-SHA-256 is | |||

truncated to 128 bits and the output of HMAC-SHA-384 is truncated to | truncated to 128 bits, and the output of HMAC-SHA-384 is truncated to | |||

192 bits. Sample test vectors are given in Appendix A. | 192 bits. Sample test vectors are given in Appendix A. | |||

Decryption is performed by removing the HMAC, verifying the HMAC | Decryption is performed by removing the HMAC, verifying the HMAC | |||

against the cipher state concatenated with the ciphertext, and then | against the cipher state 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 | |||

hmac-sha256-128 and aes256-cts-hmac-sha384-192. | aes128-cts-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 derived 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. | |||

skipping to change at page 6, line 40 ¶ | skipping to change at page 6, line 23 ¶ | |||

key-generation seed length: key size (128 or 256 bits). | key-generation seed length: key size (128 or 256 bits). | |||

string-to-key function: as defined in Section 4. | string-to-key function: as defined in Section 4. | |||

default string-to-key parameters: iteration count of decimal 32768. | default string-to-key parameters: iteration count of decimal 32768. | |||

random-to-key function: identity function. | random-to-key function: identity function. | |||

key-derivation function: KDF-HMAC-SHA2 as defined in Section 3. The | key-derivation function: KDF-HMAC-SHA2 as defined in Section 3. The | |||

key usage number is expressed as four octets in big-endian order. | key usage number is expressed as 4 octets in big-endian order. | |||

If the enctype is aes128-cts-hmac-sha256-128: | If the enctype is aes128-cts-hmac-sha256-128: | |||

Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 128) | Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 128) | |||

Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 128) | Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 128) | |||

Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 128) | Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 128) | |||

If the enctype is aes256-cts-hmac-sha384-192: | If the enctype is aes256-cts-hmac-sha384-192: | |||

Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 192) | Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 192) | |||

Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 256) | Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 256) | |||

Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 192) | Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 192) | |||

skipping to change at page 7, line 4 ¶ | skipping to change at page 6, line 34 ¶ | |||

If the enctype is aes128-cts-hmac-sha256-128: | If the enctype is aes128-cts-hmac-sha256-128: | |||

Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 128) | Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 128) | |||

Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 128) | Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 128) | |||

Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 128) | Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 128) | |||

If the enctype is aes256-cts-hmac-sha384-192: | If the enctype is aes256-cts-hmac-sha384-192: | |||

Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 192) | Kc = KDF-HMAC-SHA2(base-key, usage | 0x99, 192) | |||

Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 256) | Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA, 256) | |||

Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 192) | Ki = KDF-HMAC-SHA2(base-key, usage | 0x55, 192) | |||

cipher state: a 128-bit CBC initialization vector derived from a | cipher state: a 128-bit CBC initialization vector derived from a | |||

previous (if any) ciphertext using the same encryption key, as | previous ciphertext (if any) using the same encryption key, as | |||

specified below. | specified below. | |||

initial cipher state: all bits zero. | initial cipher state: all bits zero. | |||

encryption function: as follows, where E() is AES encryption in | encryption function: as follows, where E() is AES encryption in | |||

CBC-CS3 mode, and h is the size of truncated HMAC (128 bits or | CBC-CS3 mode, and h is the size of truncated HMAC (128 bits or 192 | |||

192 bits as described above). | bits as described above). | |||

N = random value of length 128 bits (the AES block size) | N = random value of length 128 bits (the AES block size) | |||

IV = cipher state | IV = cipher state | |||

C = E(Ke, N | plaintext, IV) | C = E(Ke, N | plaintext, IV) | |||

H = HMAC(Ki, IV | C) | H = HMAC(Ki, IV | C) | |||

ciphertext = C | H[1..h] | ciphertext = C | H[1..h] | |||

Steps to compute the 128-bit cipher state: | Steps to compute the 128-bit cipher state: | |||

L = length of C in bits | L = length of C in bits | |||

portion C into 128-bit blocks, placing any remainder | portion C into 128-bit blocks, placing any remainder of less | |||

of less than 128 bits into a final block | than 128 bits into a final block | |||

if L == 128: cipher state = C | if L == 128: cipher state = C | |||

else if L mod 128 > 0: cipher state = last full (128-bit) | else if L mod 128 > 0: cipher state = last full (128-bit) block | |||

block of C (the | of C (the next-to-last | |||

next-to-last block) | block) | |||

else if L mod 128 == 0: cipher state = next-to-last block | else if L mod 128 == 0: cipher state = next-to-last block of C | |||

of C | ||||

(note that L will never be less than 128 because of the | (Note that L will never be less than 128 because of the | |||

presence of N in the encryption input) | presence of N in the encryption input.) | |||

decryption function: as follows, where D() is AES decryption in | decryption function: as follows, where D() is AES decryption in | |||

CBC-CS3 mode, and h is the size of truncated HMAC. | CBC-CS3 mode, and h is the size of truncated HMAC. | |||

(C, H) = ciphertext (Note: H is the last h bits of the ciphertext) | (C, H) = ciphertext | |||

(Note: H is the last h bits of the ciphertext.) | ||||

IV = cipher state | IV = cipher state | |||

if H != HMAC(Ki, IV | C)[1..h] | if H != HMAC(Ki, IV | C)[1..h] | |||

stop, report error | stop, report error | |||

(N, P) = D(Ke, C, IV) | (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. | (Note: N is set to the first block of the decryption output; P is | |||

set to the rest of the output.) | ||||

cipher state = same as described above in encryption function | cipher state = same as described above in encryption function | |||

pseudo-random function: | pseudorandom function: | |||

If the enctype is aes128-cts-hmac-sha256-128: | If the enctype is aes128-cts-hmac-sha256-128: | |||

PRF = KDF-HMAC-SHA2(input-key, "prf", octet-string, 256) | PRF = KDF-HMAC-SHA2(input-key, "prf", octet-string, 256) | |||

If the enctype is aes256-cts-hmac-sha384-192: | If the enctype is aes256-cts-hmac-sha384-192: | |||

PRF = KDF-HMAC-SHA2(input-key, "prf", octet-string, 384) | PRF = KDF-HMAC-SHA2(input-key, "prf", octet-string, 384) | |||

where "prf" is the octet-string 0x707266 | where "prf" is the octet-string 0x707266 | |||

6. Checksum Parameters | 6. Checksum Parameters | |||

The following parameters apply to the checksum types hmac-sha256-128- | The following parameters apply to the checksum types | |||

aes128 and hmac-sha384-192-aes256, which are the associated checksums | hmac-sha256-128-aes128 and hmac-sha384-192-aes256, which are the | |||

for aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192, | associated checksums for aes128-cts-hmac-sha256-128 and | |||

respectively. | aes256-cts-hmac-sha384-192, respectively. | |||

associated cryptosystem: aes128-cts-hmac-sha256-128 or aes256-cts- | associated cryptosystem: aes128-cts-hmac-sha256-128 or | |||

hmac-sha384-192 as appropriate. | aes256-cts-hmac-sha384-192 as appropriate. | |||

get_mic: HMAC(Kc, message)[1..h]. | get_mic: HMAC(Kc, message)[1..h]. | |||

where h is 128 bits for checksum type hmac-sha256-128-aes128 | where h is 128 bits for checksum type hmac-sha256-128-aes128 and | |||

and 192 bits for checksum type hmac-sha384-192-aes256 | 192 bits for checksum type hmac-sha384-192-aes256 | |||

verify_mic: get_mic and compare. | verify_mic: get_mic and compare. | |||

7. IANA Considerations | 7. IANA Considerations | |||

IANA is requested to assign: | IANA has assigned encryption type numbers as follows in the "Kerberos | |||

Encryption Type Numbers" registry. | ||||

Encryption type numbers for aes128-cts-hmac-sha256-128 and | ||||

aes256-cts-hmac-sha384-192 in the Kerberos Encryption Type Numbers | ||||

registry. | ||||

Etype Encryption type Reference | etype encryption type Reference | |||

----- --------------- --------- | ----- --------------- --------- | |||

TBD1 aes128-cts-hmac-sha256-128 [this document] | 19 aes128-cts-hmac-sha256-128 RFC 8009 | |||

TBD2 aes256-cts-hmac-sha384-192 [this document] | 20 aes256-cts-hmac-sha384-192 RFC 8009 | |||

Checksum type numbers for hmac-sha256-128-aes128 and hmac-sha384-192- | IANA has assigned checksum type numbers as follows in the "Kerberos | |||

aes256 in the Kerberos Checksum Type Numbers registry. | Checksum Type Numbers" registry. | |||

Sumtype Checksum type Size Reference | sumtype Checksum type checksum Reference | |||

------- ------------- ---- --------- | value size | |||

TBD3 hmac-sha256-128-aes128 16 [this document] | ------- ------------- -------- --------- | |||

TBD4 hmac-sha384-192-aes256 24 [this document] | 19 hmac-sha256-128-aes128 16 RFC 8009 | |||

20 hmac-sha384-192-aes256 24 RFC 8009 | ||||

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 pseudorandom number generators (PRNGs) | |||

(PRNGs) can result in little or no security. The generation of | can result in little or no security. The generation of quality | |||

quality random numbers is difficult. [RFC4086] offers random number | random numbers is difficult. [RFC4086] offers guidance on random | |||

generation guidance. | number generation. | |||

This document specifies a mechanism for generating keys from | This document specifies a mechanism for generating keys from | |||

passphrases or passwords. The use of PBKDF2, a salt, and a large | passphrases or passwords. The use of PBKDF2, a salt, and a large | |||

iteration count adds some resistance to off-line dictionary attacks | iteration count adds some resistance to offline dictionary attacks by | |||

by passive eavesdroppers. Salting prevents rainbow table attacks, | passive eavesdroppers. Salting prevents "rainbow table" attacks, | |||

while large iteration counts slow password guess attempts. | while large iteration counts slow password-guess attempts. | |||

Nonetheless, computing power continues to rapidly improve, including | Nonetheless, computing power continues to rapidly improve, including | |||

the potential for use of graphics processing units (GPUs) in password | the potential for use of graphics processing units (GPUs) in | |||

guess attempts. It is important to choose strong passphrases. Use of | password-guess attempts. It is important to choose strong | |||

Kerberos extensions that protect against off-line dictionary attacks | passphrases. Use of Kerberos extensions that protect against offline | |||

should also be considered, as should the use of public key | dictionary attacks should also be considered, as should the use of | |||

cryptography for initial Kerberos authentication [RFC4556] to | public key cryptography for initial Kerberos authentication [RFC4556] | |||

eliminate the use of passwords or passphrases within the Kerberos | to eliminate the use of passwords or passphrases within the Kerberos | |||

protocol. | protocol. | |||

The NIST guidance in section 5.3 of [SP800-38A], requiring that CBC | The NIST guidance in Section 5.3 of [SP800-38A], requiring that CBC | |||

initialization vectors be unpredictable, is satisfied by the use of a | initialization vectors be unpredictable, is satisfied by the use of a | |||

random confounder as the first block of plaintext. The confounder | random confounder as the first block of plaintext. The confounder | |||

fills the cryptographic role typically played by an initialization | fills the cryptographic role typically played by an initialization | |||

vector. This approach was chosen to align with other Kerberos | vector. This approach was 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 at least 128 | The NIST guidance in Section 5.1 of [SP800-132] requires at least 128 | |||

bits of the salt to be randomly generated. The string-to-key function | bits of the salt to be randomly generated. The string-to-key | |||

as defined in [RFC3961] requires the salt to be valid UTF-8 strings | function as defined in [RFC3961] requires the salt to be valid UTF-8 | |||

[RFC3629]. Not every 128-bit random string will be valid UTF-8, so a | strings [RFC3629]. Not every 128-bit random string will be valid | |||

UTF-8 compatible encoding would be needed to encapsulate the random | UTF-8, so a UTF-8-compatible encoding would be needed to encapsulate | |||

bits. However, using a salt containing a random portion may have the | the random bits. However, using a salt containing a random portion | |||

following issues with some implementations: | may have the following issues with some implementations: | |||

* Cross-realm krbtgt keys are typically managed by entering the | * Keys for cross-realm krbtgt services [RFC4120] are typically | |||

same password at two KDCs to get the same keys. If each KDC uses | managed by entering the same password at two Key Distribution | |||

a random salt, they won't have the same keys. | Centers (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. | * Random salts may interfere with checking of password history. | |||

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 | |||

enc-type name "aes256-cts-hmac-sha384-192", the truncation of the | enc-type name "aes256-cts-hmac-sha384-192", the truncation of the | |||

HMAC-SHA-384 output to 192-bits results in an overall 192-bit level | HMAC-SHA-384 output to 192 bits results in an overall 192-bit level | |||

of security. | of security. | |||

9. Acknowledgements | 9. References | |||

Kelley Burgin was employed at the National Security Agency during | 9.1. Normative References | |||

much of the work on this document. | ||||

10. References | [FIPS180] National Institute of Standards and Technology, "Secure | |||

Hash Standard", FIPS PUB 180-4, | ||||

DOI 10.6028/NIST.FIPS.180-4, August 2015. | ||||

10.1. Normative References | [FIPS197] National Institute of Standards and Technology, | |||

"Advanced Encryption Standard (AES)", FIPS PUB 197, | ||||

November 2001. | ||||

[RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||

Authentication", RFC 2104, February 1997. | Hashing for Message Authentication", RFC 2104, | |||

DOI 10.17487/RFC2104, February 1997, | ||||

<http://www.rfc-editor.org/info/rfc2104>. | ||||

[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography | [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography | |||

Specification Version 2.0", RFC 2898, September 2000. | Specification Version 2.0", RFC 2898, | |||

DOI 10.17487/RFC2898, September 2000, | ||||

<http://www.rfc-editor.org/info/rfc2898>. | ||||

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | |||

10646", RFC 3629, November 2003. | 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November | |||

2003, <http://www.rfc-editor.org/info/rfc3629>. | ||||

[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for | [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for | |||

Kerberos 5", RFC 3961, February 2005. | Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February | |||

2005, <http://www.rfc-editor.org/info/rfc3961>. | ||||

[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) | [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) | |||

Encryption for Kerberos 5", RFC 3962, February 2005. | Encryption for Kerberos 5", RFC 3962, | |||

DOI 10.17487/RFC3962, February 2005, | ||||

[FIPS180] National Institute of Standards and Technology, "Secure | <http://www.rfc-editor.org/info/rfc3962>. | |||

Hash Standard", FIPS PUB 180-4, August 2015. | ||||

[FIPS197] National Institute of Standards and Technology, | ||||

"Advanced Encryption Standard (AES)", FIPS PUB 197, | ||||

November 2001. | ||||

[SP800-38A+] National Institute of Standards and Technology, | [SP800-38A+] National Institute of Standards and Technology, | |||

"Recommendation for Block Cipher Modes of Operation: | "Recommendation for Block Cipher Modes of Operation: | |||

Three Variants of Ciphertext Stealing for CBC Mode", | Three Variants of Ciphertext Stealing for CBC Mode", | |||

NIST Special Publication 800-38A Addendum, October 2010. | NIST Special Publication 800-38A Addendum, October 2010. | |||

[SP800-108] National Institute of Standards and Technology, | [SP800-108] National Institute of Standards and Technology, | |||

"Recommendation for Key Derivation Using Pseudorandom | "Recommendation for Key Derivation Using Pseudorandom | |||

Functions", NIST Special Publication 800-108, October | Functions", NIST Special Publication 800-108, October | |||

2009. | 2009. | |||

10.2. Informative References | 9.2. Informative References | |||

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | |||

"Randomness Requirements for Security", BCP 106, RFC | "Randomness Requirements for Security", BCP 106, | |||

4086, June 2005. | RFC 4086, DOI 10.17487/RFC4086, June 2005, | |||

<http://www.rfc-editor.org/info/rfc4086>. | ||||

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The | ||||

Kerberos Network Authentication Service (V5)", RFC 4120, | ||||

DOI 10.17487/RFC4120, July 2005, | ||||

<http://www.rfc-editor.org/info/rfc4120>. | ||||

[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for | ||||

Initial Authentication in Kerberos (PKINIT)", RFC 4556, | ||||

DOI 10.17487/RFC4556, June 2006, | ||||

<http://www.rfc-editor.org/info/rfc4556>. | ||||

[SP800-38A] National Institute of Standards and Technology, | [SP800-38A] National Institute of Standards and Technology, | |||

"Recommendation for Block Cipher Modes of Operation: | "Recommendation for Block Cipher Modes of Operation: | |||

Methods and Techniques", NIST Special Publication | Methods and Techniques", NIST Special Publication | |||

800-38A, December 2001. | 800-38A, December 2001. | |||

[SP800-132] National Institute of Standards and Technology, | [SP800-132] National Institute of Standards and Technology, | |||

"Recommendation for Password-Based Key Derivation, Part | "Recommendation for Password-Based Key Derivation, Part | |||

1: Storage Applications", NIST Special Publication 800- | 1: Storage Applications", NIST Special Publication | |||

132, June 2010. | 800-132, June 2010. | |||

Appendix A. Test Vectors | Appendix A. Test Vectors | |||

Sample results for string-to-key conversion: | Sample results for string-to-key conversion: | |||

-------------------------------------------- | -------------------------------------------- | |||

Iteration count = 32768 | Iteration count = 32768 | |||

Pass phrase = "password" | Pass phrase = "password" | |||

Saltp for creating 128-bit base-key: | Saltp for creating 128-bit base-key: | |||

61 65 73 31 32 38 2D 63 74 73 2D 68 6D 61 63 2D | 61 65 73 31 32 38 2D 63 74 73 2D 68 6D 61 63 2D | |||

73 68 61 32 35 36 2D 31 32 38 00 10 DF 9D D7 83 | 73 68 61 32 35 36 2D 31 32 38 00 10 DF 9D D7 83 | |||

E5 BC 8A CE A1 73 0E 74 35 5F 61 41 54 48 45 4E | E5 BC 8A CE A1 73 0E 74 35 5F 61 41 54 48 45 4E | |||

41 2E 4D 49 54 2E 45 44 55 72 61 65 62 75 72 6E | 41 2E 4D 49 54 2E 45 44 55 72 61 65 62 75 72 6E | |||

(The saltp is "aes128-cts-hmac-sha256-128" | 0x00 | | (The saltp is "aes128-cts-hmac-sha256-128" | 0x00 | | |||

random 16 byte valid UTF-8 sequence | "ATHENA.MIT.EDUraeburn") | random 16-byte valid UTF-8 sequence | "ATHENA.MIT.EDUraeburn") | |||

128-bit base-key: | 128-bit base-key: | |||

08 9B CA 48 B1 05 EA 6E A7 7C A5 D2 F3 9D C5 E7 | 08 9B CA 48 B1 05 EA 6E A7 7C A5 D2 F3 9D C5 E7 | |||

Saltp for creating 256-bit base-key: | Saltp for creating 256-bit base-key: | |||

61 65 73 32 35 36 2D 63 74 73 2D 68 6D 61 63 2D | 61 65 73 32 35 36 2D 63 74 73 2D 68 6D 61 63 2D | |||

73 68 61 33 38 34 2D 31 39 32 00 10 DF 9D D7 83 | 73 68 61 33 38 34 2D 31 39 32 00 10 DF 9D D7 83 | |||

E5 BC 8A CE A1 73 0E 74 35 5F 61 41 54 48 45 4E | E5 BC 8A CE A1 73 0E 74 35 5F 61 41 54 48 45 4E | |||

41 2E 4D 49 54 2E 45 44 55 72 61 65 62 75 72 6E | 41 2E 4D 49 54 2E 45 44 55 72 61 65 62 75 72 6E | |||

(The saltp is "aes256-cts-hmac-sha384-192" | 0x00 | | (The saltp is "aes256-cts-hmac-sha384-192" | 0x00 | | |||

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 | |||

skipping to change at page 12, line 28 ¶ | skipping to change at page 14, line 7 ¶ | |||

BA 41 F2 8F AF 69 E7 3D | BA 41 F2 8F AF 69 E7 3D | |||

Ke value for key usage 2 (label = 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 | 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 | A5 EB 1C 82 51 60 C3 83 12 98 0C 44 2E 5C 7E 49 | |||

Ki value for key usage 2 (label = 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 | 69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 | |||

22 C4 D0 0F FC 23 ED 1F | 22 C4 D0 0F FC 23 ED 1F | |||

Sample encryptions (all using the default cipher state): | Sample encryptions (all using the default cipher state): | |||

-------------------------------------------------------- | -------------------------------------------------------- | |||

These sample encryptions use the above sample key | ||||

derivation results, including use of the same | These sample encryptions use the above sample key derivation results, | |||

base-key and key usage values. | including use of the same base-key and key usage values. | |||

The following test vectors are for | The following test vectors are for | |||

enctype aes128-cts-hmac-sha256-128: | enctype aes128-cts-hmac-sha256-128: | |||

Plaintext: (empty) | Plaintext: (empty) | |||

Confounder: | Confounder: | |||

7E 58 95 EA F2 67 24 35 BA D8 17 F5 45 A3 71 48 | 7E 58 95 EA F2 67 24 35 BA D8 17 F5 45 A3 71 48 | |||

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): | |||

skipping to change at page 16, line 4 ¶ | skipping to change at page 18, line 7 ¶ | |||

FE F6 EC B6 47 D6 29 5F AE 07 7A 1F EB 51 75 08 | FE F6 EC B6 47 D6 29 5F AE 07 7A 1F EB 51 75 08 | |||

D2 C1 6B 41 92 E0 1F 62 | D2 C1 6B 41 92 E0 1F 62 | |||

Ciphertext: | Ciphertext: | |||

40 01 3E 2D F5 8E 87 51 95 7D 28 78 BC D2 D6 FE | 40 01 3E 2D F5 8E 87 51 95 7D 28 78 BC D2 D6 FE | |||

10 1C CF D5 56 CB 1E AE 79 DB 3C 3E E8 64 29 F2 | 10 1C CF D5 56 CB 1E AE 79 DB 3C 3E E8 64 29 F2 | |||

B2 A6 02 AC 86 FE F6 EC B6 47 D6 29 5F AE 07 7A | B2 A6 02 AC 86 FE F6 EC B6 47 D6 29 5F AE 07 7A | |||

1F EB 51 75 08 D2 C1 6B 41 92 E0 1F 62 | 1F EB 51 75 08 D2 C1 6B 41 92 E0 1F 62 | |||

Sample checksums: | Sample checksums: | |||

----------------- | ----------------- | |||

These sample checksums use the above sample key | ||||

derivation results, including use of the same | These sample checksums use the above sample key derivation results, | |||

base-key and key usage values. | including use of the same base-key and key usage values. | |||

Checksum type: hmac-sha256-128-aes128 | Checksum type: hmac-sha256-128-aes128 | |||

128-bit HMAC key (Kc): | 128-bit HMAC key (Kc): | |||

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 | |||

Plaintext: | Plaintext: | |||

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||

10 11 12 13 14 | 10 11 12 13 14 | |||

Checksum: | Checksum: | |||

D7 83 67 18 66 43 D6 7B 41 1C BA 91 39 FC 1D EE | D7 83 67 18 66 43 D6 7B 41 1C BA 91 39 FC 1D EE | |||

skipping to change at page 17, line 6 ¶ | skipping to change at page 19, line 6 ¶ | |||

EF 57 18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 C4 | EF 57 18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 C4 | |||

BA 41 F2 8F AF 69 E7 3D | BA 41 F2 8F AF 69 E7 3D | |||

Plaintext: | Plaintext: | |||

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | |||

10 11 12 13 14 | 10 11 12 13 14 | |||

Checksum: | Checksum: | |||

45 EE 79 15 67 EE FC A3 7F 4A C1 E0 22 2D E8 0D | 45 EE 79 15 67 EE FC A3 7F 4A C1 E0 22 2D E8 0D | |||

43 C3 BF A0 66 99 67 2A | 43 C3 BF A0 66 99 67 2A | |||

Sample pseudorandom function (PRF) invocations: | Sample pseudorandom function (PRF) invocations: | |||

---------------------------------------- | ----------------------------------------------- | |||

PRF input octet-string: "test" (0x74657374) | PRF input octet-string: "test" (0x74657374) | |||

enctype aes128-cts-hmac-sha256-128: | enctype aes128-cts-hmac-sha256-128: | |||

input-key value / HMAC-SHA-256 key: | input-key value / HMAC-SHA-256 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 | |||

HMAC-SHA-256 input message: | HMAC-SHA-256 input message: | |||

00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 00 | 00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 00 | |||

PRF output: | PRF output: | |||

9D 18 86 16 F6 38 52 FE 86 91 5B B8 40 B4 A8 86 | 9D 18 86 16 F6 38 52 FE 86 91 5B B8 40 B4 A8 86 | |||

skipping to change at page 18, line 5 ¶ | skipping to change at page 19, line 30 ¶ | |||

input-key value / HMAC-SHA-384 key: | input-key value / HMAC-SHA-384 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 | |||

00 EB 48 36 47 2E A8 A0 26 D1 6B 71 82 46 0C 52 | 00 EB 48 36 47 2E A8 A0 26 D1 6B 71 82 46 0C 52 | |||

HMAC-SHA-384 input message: | HMAC-SHA-384 input message: | |||

00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 80 | 00 00 00 01 70 72 66 00 74 65 73 74 00 00 01 80 | |||

PRF output: | PRF output: | |||

98 01 F6 9A 36 8C 2B F6 75 E5 95 21 E1 77 D9 A0 | 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 | 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 | B3 C1 B6 2A D1 B8 55 33 60 D1 73 67 EB 15 14 D2 | |||

Acknowledgements | ||||

Kelley Burgin was employed at the National Security Agency during | ||||

much of the work on this document. | ||||

Authors' Addresses | Authors' Addresses | |||

Michael J. Jenkins | Michael J. Jenkins | |||

National Security Agency | National Security Agency | |||

EMail: mjjenki@tycho.ncsc.mil | Email: mjjenki@tycho.ncsc.mil | |||

Michael A. Peck | Michael A. Peck | |||

The MITRE Corporation | The MITRE Corporation | |||

EMail: mpeck@mitre.org | Email: mpeck@mitre.org | |||

Kelley W. Burgin | Kelley W. Burgin | |||

Email: kelley.burgin@gmail.com | Email: kelley.burgin@gmail.com | |||

End of changes. 81 change blocks. | ||||

180 lines changed or deleted | | 201 lines changed or added | ||

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