RFC 4868
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec 💖
Okay bestie, this is RFC 4868 🎀, a Standards Track document from May 2007. It was written by S. Kelly of Aruba Networks and S. Frankel of NIST. The header doesn't list any Obsoletes or Updates entries, so it doesn't replace or change any earlier RFC. It's all about using HMAC with SHA-256, SHA-384, and SHA-512 inside IPsec, and it's giving main character energy 🦋✨
Status of This Memo 📜
This document is an Internet standards track protocol spec for the Internet community 🌸 It also asks for discussion and suggestions for improvements. If you want to know where the protocol stands, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 💜
Copyright Notice ©️
Copyright (C) The IETF Trust (2007). 🌈
Abstract 🔥
Okay, so the big idea is this: Hashed Message Authentication Mode (HMAC) gets paired with SHA-256, SHA-384, and SHA-512 and used in IPsec 🔐 These combos can power data origin authentication and integrity verification for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols. They also work as Pseudo-Random Functions (PRFs) for IKE and IKEv2 ✨
The authentication versions get truncated output, and they're called HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF versions are NOT truncated, and they go by PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512 💅
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The HMAC-SHA-256+ Algorithms . . . . . . . . . . . . . . . . . 3
2.1. Keying Material . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Data Origin Authentication and Integrity
Verification Usage . . . . . . . . . . . . . . . . . . 4
2.1.2. Pseudo-Random Function (PRF) Usage . . . . . . . . . . 4
2.1.3. Randomness and Key Strength . . . . . . . . . . . . . 5
2.1.4. Key Distribution . . . . . . . . . . . . . . . . . . . 5
2.1.5. Refreshing Keys . . . . . . . . . . . . . . . . . . . 5
2.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Using HMAC-SHA-256+ as PRFs in IKE and IKEv2 . . . . . . . 7
2.5. Interactions with the ESP, IKE, or IKEv2 Cipher
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6. HMAC-SHA-256+ Parameter Summary . . . . . . . . . . . . . 7
2.7. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 7
2.7.1. PRF Test Vectors . . . . . . . . . . . . . . . . . . . 8
2.7.2. Authenticator Test Vectors . . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 17
3.1. HMAC Key Length vs Truncation Length . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . . 201. Introduction 🧚
Okay, this section sets the scene 🌸 It describes SHA-256, SHA-384, and SHA-512 [SHA2-1] combined with HMAC [HMAC] as data origin authentication and integrity verification mechanisms for the IPsec AH [AH], ESP [ESP], IKE [IKE], and IKEv2 [IKEv2] protocols. Output truncation is specified for these variants, with the algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The truncation lengths were picked to match the birthday bound for each algorithm 🎯
The doc also describes untruncated versions as PRFs for IKE and IKEv2. Those are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. For ease of reference, the PRFs and the authentication variants are collectively called "the HMAC-SHA-256+ algorithms" 💖
Here's the vibe check 💅 The PRF variants exist to give you secure pseudo-random functions for making keying material and other protocol-specific numbers. The authentication variants exist to make sure packets are authentic and can't be changed in transit 🔒 How strong HMAC-SHA-256+ is in either case depends on how far the secret key is distributed and how unpredictable it is. If the key is unpredictable and only the sender and recipient know it, these algorithms make sure only parties holding an identical key can derive the associated values 🫶
2. The HMAC-SHA-256+ Algorithms 🌈
[SHA2-1] and [SHA2-2] describe the underlying SHA-256, SHA-384, and SHA-512 algorithms, and [HMAC] describes HMAC. HMAC gives you a framework for plugging in different hash algorithms like SHA-256, and [SHA256+] describes how these algorithms get used together. The next sections break down the characteristics and requirements of the HMAC-SHA-256+ algorithms when they're used with IPsec 🎀
2.1. Keying Material 🔑
Keying material requirements depend on whether the algorithm is acting as a PRF or as an authentication/integrity mechanism. For authentication/integrity, key lengths are fixed based on the output length of the algorithm in use. For PRFs, key lengths can vary, but there's guidance to keep things interoperable. We'll get into the details below ✨
Before we get into key requirements for each usage, let's define some terms we'll use:
- Block size: the size of the data block the underlying hash algorithm operates on. For SHA-256, this is 512 bits. For SHA-384 and SHA-512, this is 1024 bits.
- Output length: the size of the hash value the underlying hash algorithm produces. For SHA-256, this is 256 bits. For SHA-384, this is 384 bits. For SHA-512, this is 512 bits.
- Authenticator length: the size of the "authenticator" in bits. This only applies to authentication/integrity algorithms, and it refers to the bit length left after truncation. In this spec, it's always half the output length of the underlying hash algorithm 💜
2.1.1. Data Origin Authentication and Integrity Verification Usage 🛡️
HMAC-SHA-256+ are secret key algorithms 🤫 [HMAC] doesn't specify a fixed key length, but this spec says that when the algorithm is used as an integrity/authentication algorithm, a fixed key length equal to the output length of the hash function MUST be supported. Key lengths other than the output length of the associated hash function MUST NOT be supported 🚫
These key length rules come partly from the recommendations in [HMAC]. Key lengths shorter than the output length weaken security strength, and keys longer than the output length don't meaningfully add security strength. They also come partly from the fact that variable-length keys for IPsec authenticator functions would cause interoperability issues 😭
2.1.2. Pseudo-Random Function (PRF) Usage 🌸
IKE and IKEv2 use PRFs to generate keying material and to authenticate the IKE Security Association. The IKEv2 spec separates PRFs with fixed key sizes from PRFs with variable key sizes, so we've got some extra guidance for that below 💅
When a PRF from this document is used with IKE or IKEv2, it's treated as having a variable key length. Keys get derived in the following ways. (This just repeats what [HMAC] already says 🙈)
- If the key length is exactly the algorithm block size, use it as-is.
- If the key is shorter than the block size, lengthen it to exactly the block size by padding it on the right with zero bits. Heads up though, [HMAC] strongly discourages a key length less than the output length. We still describe how to handle shorter lengths, though, because shorter lengths are typically what gets chosen for IKE or IKEv2 pre-shared keys 🔑
- If the key is longer than the block size, shorten it by computing the corresponding hash algorithm's output over the entire key value, and treat that output value as your HMAC key. This always gives you a key shorter than the block size, so that key will need zero-padding (as described above) before you use it 🌀
2.1.3. Randomness and Key Strength 🎲
[HMAC] talks about key material requirements, including a requirement for strong randomness. So a strong pseudo-random function MUST be used to generate the required key for HMAC-SHA-256+. As of this writing, there are no published weak keys for any HMAC-SHA-256+ algorithm 🙌
2.1.4. Key Distribution 📬
[ARCH] describes the general mechanism for getting keying material when multiple keys are needed for a single SA. An example is when an ESP SA needs one key for confidentiality and another for authentication. To provide data origin authentication and integrity verification, the key distribution mechanism must make sure unique keys are allocated and that they're only distributed to the parties in the communication 🫶
2.1.5. Refreshing Keys 🔄
Right now, there are no practical attacks against the algorithms recommended here, especially against the key sizes recommended here 🥰 But as [HMAC] notes, "...periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key".
Let's put that in perspective 👑 This spec requires 256-, 384-, or 512-bit keys produced by a strong PRF for use as a MAC. A brute force attack on keys like that would take longer than the universe has existed. Weak keys, like dictionary words, would be dramatically less resistant to attack 💀 It's important to think about all of these points, plus the specific threat model for your application and the current state of the art regarding attacks on SHA-256, SHA-384, and SHA-512, when you decide on an appropriate upper bound for HMAC key lifetimes ⏳
2.2. Padding 🎀
The HMAC-SHA-256 algorithms work on 512-bit blocks of data, while HMAC-SHA-384 and HMAC-SHA-512 work on 1024-bit blocks. Padding requirements are specified in [SHA2-1] as part of the underlying SHA-256, SHA-384, and SHA-512 algorithms. So if you implement according to [SHA2-1], you don't need to add any extra padding for the HMAC-SHA-256+ algorithms specified here 🧁 As for "implicit packet padding" as defined in [AH], no implicit packet padding is required. Slay 💖
2.3. Truncation 🎀
okay so the HMAC-SHA-256+ algorithms each spit out an nnn-bit value, where nnn is just the output bit length of the algorithm, like HMAC-SHA-nnn. 🧚 When you want to use it as an authenticator, that nnn-bit value can get truncated, as described in [HMAC]. When it's being used for data origin authentication and integrity verification in ESP, AH, IKE, or IKEv2, a truncated value made from the first nnn/2 bits (exactly half the algorithm output size) MUST be supported. 💖 No other authenticator value lengths are supported by this spec, so don't go looking for them 🙅♀️
Sending side: the truncated value gets stored in the authenticator field. ✨ Receiving side: the whole nnn-bit value gets computed, then the first nnn/2 bits get compared to whatever is sitting in the authenticator field. The value of 'nnn' depends on which algorithm was negotiated, so keep track of that 💅
[HMAC] talks about the security benefits of truncating the output MAC value, and honestly it's pretty pro-truncation, encouraging HMAC users to do it. 🦋 In the IPsec context, a truncation length of nnn/2 bits was picked because it lines up with the birthday attack bound for each of the HMAC-SHA-256+ algorithms. Bonus: it also keeps the extra bits on the wire as small as possible. Two wins, one choice, iconic 👑
2.4. Using HMAC-SHA-256+ as PRFs in IKE and IKEv2 🌸
PRF-HMAC-SHA-256 is basically the same thing as HMAC-SHA-256-128, except variable-length keys are allowed, and the truncation step is NOT performed. 🙈 Same energy for the other two: PRF-HMAC-SHA-384 and PRF-HMAC-SHA-512 match HMAC-SHA-384-192 and HMAC-SHA-512-256, respectively. Again, variable-length keys are permitted, and truncation is NOT performed. Just a PRF with no chopping, periodt 🧚
2.5. Interactions with the ESP, IKE, or IKEv2 Cipher Mechanisms 🫶
As of this writing, there are no known issues that preclude the use of the HMAC-SHA-256+ algorithms with any specific cipher algorithm. Lowkey the most chill section in the whole doc 😌✨
2.6. HMAC-SHA-256+ Parameter Summary 📊
This table is the cheat sheet 🍓 It sums up the different quantities tied to the HMAC-SHA-256+ algorithms. In the table, "var" just means "variable", so if you see it, that's the vibe.
+------------------+--------+--------+--------+--------+------------+
| Algorithm | Block | Output | Trunc. | Key | Algorithm |
| ID | Size | Length | Length | Length | Type |
+==================+========+========+========+========+============+
| HMAC-SHA-256-128 | 512 | 256 | 128 | 256 | auth/integ |
+------------------+--------+--------+--------+--------+------------+
| HMAC-SHA-384-192 | 1024 | 384 | 192 | 384 | auth/integ |
+------------------+--------+--------+--------+--------+------------+
| HMAC-SHA-512-256 | 1024 | 512 | 256 | 512 | auth/integ |
+------------------+--------+--------+--------+--------+------------+
| PRF-HMAC-SHA-256 | 512 | 256 | (none) | var | PRF |
+------------------+--------+--------+--------+--------+------------+
| PRF-HMAC-SHA-384 | 1024 | 384 | (none) | var | PRF |
+------------------+--------+--------+--------+--------+------------+
| PRF-HMAC-SHA-512 | 1024 | 512 | (none) | var | PRF |
+------------------+--------+--------+--------+--------+------------+2.7. Test Vectors 🧪
These test cases list the key, the data, and the resulting authenticator and/or PRF values for each algorithm. Keys and data are either ASCII character strings (wrapped in double quotes) or hexadecimal numbers. 💜 If a value is an ASCII string, then the HMAC computation for that test case DOES NOT include the trailing null character ('\0') of the string. Be careful with that one, bestie 🙏 All the computed HMAC values are hexadecimal numbers.
2.7.1. PRF Test Vectors 🦄
These test cases were borrowed from RFC 4231 [HMAC-TEST], which is honestly such a W move. For reference implementations of the underlying hash algorithms, check out [SHA256+]. Quick reminder: for testing purposes, PRF output is considered to be simply the untruncated algorithm output. ✨
Test Case PRF-1:
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b (20 bytes)
Data = 4869205468657265 ("Hi There")
PRF-HMAC-SHA-256 = b0344c61d8db38535ca8afceaf0bf12b
881dc200c9833da726e9376c2e32cff7
PRF-HMAC-SHA-384 = afd03944d84895626b0825f4ab46907f
15f9dadbe4101ec682aa034c7cebc59c
faea9ea9076ede7f4af152e8b2fa9cb6
PRF-HMAC-SHA-512 = 87aa7cdea5ef619d4ff0b4241a1d6cb0
2379f4e2ce4ec2787ad0b30545e17cde
daa833b7d6b8a702038b274eaea3f4e4
be9d914eeb61f1702e696c203a126854Test Case PRF-2:
Key = 4a656665 ("Jefe")
Data = 7768617420646f2079612077616e7420 ("what do ya want ")
666f72206e6f7468696e673f ("for nothing?")
PRF-HMAC-SHA-256 = 5bdcc146bf60754e6a042426089575c7
5a003f089d2739839dec58b964ec3843
PRF-HMAC-SHA-384 = af45d2e376484031617f78d2b58a6b1b
9c7ef464f5a01b47e42ec3736322445e
8e2240ca5e69e2c78b3239ecfab21649
PRF-HMAC-SHA-512 = 164b7a7bfcf819e2e395fbe73b56e0a3
87bd64222e831fd610270cd7ea250554
9758bf75c05a994a6d034f65f8f0e6fd
caeab1a34d4a6b4b636e070a38bce737Test Case PRF-3:
Key aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaa (20 bytes)
Data = dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddd (50 bytes)
PRF-HMAC-SHA-256 = 773ea91e36800e46854db8ebd09181a7
2959098b3ef8c122d9635514ced565fe
PRF-HMAC-SHA-384 = 88062608d3e6ad8a0aa2ace014c8a86f
0aa635d947ac9febe83ef4e55966144b
2a5ab39dc13814b94e3ab6e101a34f27
PRF-HMAC-SHA-512 = fa73b0089d56a284efb0f0756c890be9
b1b5dbdd8ee81a3655f83e33b2279d39
bf3e848279a722c806b485a47e67c807
b946a337bee8942674278859e13292fbTest Case PRF-4:
Key = 0102030405060708090a0b0c0d0e0f10
111213141516171819 (25 bytes)
Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcd (50 bytes)
PRF-HMAC-SHA-256 = 82558a389a443c0ea4cc819899f2083a
85f0faa3e578f8077a2e3ff46729665b
PRF-HMAC-SHA-384 = 3e8a69b7783c25851933ab6290af6ca7
7a9981480850009cc5577c6e1f573b4e
6801dd23c4a7d679ccf8a386c674cffb
PRF-HMAC-SHA-512 = b0ba465637458c6990e5a8c5f61d4af7
e576d97ff94b872de76f8050361ee3db
a91ca5c11aa25eb4d679275cc5788063
a5f19741120c4f2de2adebeb10a298ddTest Case PRF-5:
Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaa (131 bytes)
Data = 54657374205573696e67204c61726765 ("Test Using Large")
72205468616e20426c6f636b2d53697a ("r Than Block-Siz")
65204b6579202d2048617368204b6579 ("e Key - Hash Key")
204669727374 (" First")
PRF-HMAC-SHA-256 = 60e431591ee0b67f0d8a26aacbf5b77f
8e0bc6213728c5140546040f0ee37f54
PRF-HMAC-SHA-384 = 4ece084485813e9088d2c63a041bc5b4
4f9ef1012a2b588f3cd11f05033ac4c6
0c2ef6ab4030fe8296248df163f44952
PRF-HMAC-SHA-512 = 80b24263c7c1a3ebb71493c1dd7be8b4
9b46d1f41b4aeec1121b013783f8f352
6b56d037e05f2598bd0fd2215d6a1e52
95e64f73f63f0aec8b915a985d786598Test Case PRF-6:
Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaa (131 bytes)
Data = 54686973206973206120746573742075 ("This is a test u")
73696e672061206c6172676572207468 ("sing a larger th")
616e20626c6f636b2d73697a65206b65 ("an block-size ke")
7920616e642061206c61726765722074 ("y and a larger t")
68616e20626c6f636b2d73697a652064 ("han block-size d")
6174612e20546865206b6579206e6565 ("ata. The key nee")
647320746f2062652068617368656420 ("ds to be hashed ")
6265666f7265206265696e6720757365 ("before being use")
642062792074686520484d414320616c ("d by the HMAC al")
676f726974686d2e ("gorithm.")
PRF-HMAC-SHA-256 = 9b09ffa71b942fcb27635fbcd5b0e944
bfdc63644f0713938a7f51535c3a35e2
PRF-HMAC-SHA-384 = 6617178e941f020d351e2f254e8fd32c
602420feb0b8fb9adccebb82461e99c5
a678cc31e799176d3860e6110c46523e
PRF-HMAC-SHA-512 = e37b6a775dc87dbaa4dfa9f96e5e3ffd
debd71f8867289865df5a32d20cdc944
b6022cac3c4982b10d5eeb55c3e4de15
134676fb6de0446065c97440fa8c6a582.7.2. Authenticator Test Vectors 🔐
The next sections are test cases for HMAC-SHA256-128, HMAC-SHA384-192, and HMAC-SHA512-256. ✨ PRF outputs are included too, just for convenience. These test cases were generated using the SHA256+ reference code provided in [SHA256+]. 🎀
2.7.2.1. SHA256 Authentication Test Vectors
Test Case AUTH256-1:
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (32 bytes)
Data = 4869205468657265 ("Hi There")
PRF-HMAC-SHA-256 = 198a607eb44bfbc69903a0f1cf2bbdc5
ba0aa3f3d9ae3c1c7a3b1696a0b68cf7
HMAC-SHA-256-128 = 198a607eb44bfbc69903a0f1cf2bbdc5Test Case AUTH256-2:
Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
Data = 7768617420646f2079612077616e7420 ("what do ya want ")
666f72206e6f7468696e673f ("for nothing?")
PRF-HMAC-SHA-256 = 167f928588c5cc2eef8e3093caa0e87c
9ff566a14794aa61648d81621a2a40c6
HMAC-SHA-256-128 = 167f928588c5cc2eef8e3093caa0e87cTest Case AUTH256-3:
Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (32 bytes)
Data = dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddd (50 bytes)
PRF-HMAC-SHA-256 = cdcb1220d1ecccea91e53aba3092f962
e549fe6ce9ed7fdc43191fbde45c30b0
HMAC-SHA-256-128 = cdcb1220d1ecccea91e53aba3092f962
Test Case AUTH256-4:
Key = 0102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f20 (32 bytes)
Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcd (50 bytes)
PRF-HMAC-SHA-256 = 372efcf9b40b35c2115b1346903d2ef4
2fced46f0846e7257bb156d3d7b30d3f
HMAC-SHA-256-128 = 372efcf9b40b35c2115b1346903d2ef42.7.2.2. SHA384 Authentication Test Vectors
Test Case AUTH384-1:
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (48 bytes)
Data = 4869205468657265 ("Hi There")
PRF-HMAC-SHA-384 = b6a8d5636f5c6a7224f9977dcf7ee6c7
fb6d0c48cbdee9737a959796489bddbc
4c5df61d5b3297b4fb68dab9f1b582c2
HMAC-SHA-384-128 = b6a8d5636f5c6a7224f9977dcf7ee6c7
fb6d0c48cbdee973Test Case AUTH384-2:
Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
Data = 7768617420646f2079612077616e7420 ("what do ya want ")
666f72206e6f7468696e673f ("for nothing?")
PRF-HMAC-SHA-384 = 2c7353974f1842fd66d53c452ca42122
b28c0b594cfb184da86a368e9b8e16f5
349524ca4e82400cbde0686d403371c9
HMAC-SHA-384-192 = 2c7353974f1842fd66d53c452ca42122
b28c0b594cfb184dTest Case AUTH384-3:
Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (48 bytes)
Data = dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddd (50 bytes)
PRF-HMAC-SHA-384 = 809f439be00274321d4a538652164b53
554a508184a0c3160353e3428597003d
35914a18770f9443987054944b7c4b4a
HMAC-SHA-384-192 = 809f439be00274321d4a538652164b53
554a508184a0c316Test Case AUTH384-4:
Key = 0102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f20
0a0b0c0d0e0f10111213141516171819 (48 bytes)
Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcd (50 bytes)
PRF-HMAC-SHA-384 = 5b540085c6e6358096532b2493609ed1
cb298f774f87bb5c2ebf182c83cc7428
707fb92eab2536a5812258228bc96687
HMAC-SHA-384-192 = 5b540085c6e6358096532b2493609ed1
cb298f774f87bb5c2.7.2.3. SHA512 Authentication Test Vectors
Test Case AUTH512-1:
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (64 bytes)
Data = 4869205468657265 ("Hi There")
PRF-HMAC-SHA-512 = 637edc6e01dce7e6742a99451aae82df
23da3e92439e590e43e761b33e910fb8
ac2878ebd5803f6f0b61dbce5e251ff8
789a4722c1be65aea45fd464e89f8f5b
HMAC-SHA-512-256 = 637edc6e01dce7e6742a99451aae82df
23da3e92439e590e43e761b33e910fb8Test Case AUTH512-2:
Key = 4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
4a6566654a6566654a6566654a656665 ("JefeJefeJefeJefe")
Data = 7768617420646f2079612077616e7420 ("what do ya want ")
666f72206e6f7468696e673f ("for nothing?")
PRF-HMAC-SHA-512 = cb370917ae8a7ce28cfd1d8f4705d614
1c173b2a9362c15df235dfb251b15454
6aa334ae9fb9afc2184932d8695e397b
fa0ffb93466cfcceaae38c833b7dba38
HMAC-SHA-512-256 = cb370917ae8a7ce28cfd1d8f4705d614
1c173b2a9362c15df235dfb251b15454Test Case AUTH512-3:
Key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (64 bytes)
Data = dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddd
dddd (50 bytes)
PRF-HMAC-SHA-512 = 2ee7acd783624ca9398710f3ee05ae41
b9f9b0510c87e49e586cc9bf961733d8
623c7b55cebefccf02d5581acc1c9d5f
b1ff68a1de45509fbe4da9a433922655
HMAC-SHA-512-256 = 2ee7acd783624ca9398710f3ee05ae41
b9f9b0510c87e49e586cc9bf961733d8Test Case AUTH512-4:
Key = 0a0b0c0d0e0f10111213141516171819
0102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f20
2122232425262728292a2b2c2d2e2f30
3132333435363738393a3b3c3d3e3f40 (64 bytes)
Data = cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd
cdcd (50 bytes)
PRF-HMAC-SHA-512 = 5e6688e5a3daec826ca32eaea224eff5
e700628947470e13ad01302561bab108
b8c48cbc6b807dcfbd850521a685babc
7eae4a2a2e660dc0e86b931d65503fd2
HMAC-SHA-512-256 = 5e6688e5a3daec826ca32eaea224eff5
e700628947470e13ad01302561bab1083. Security Considerations 🔐
okay bestie, this part is serious, so let's get into it 🫶 In a general sense, the security of the HMAC-SHA-256+ algorithms comes from two places: the strength of the underlying hash algorithm, and the extra strength you get from the HMAC construct. As of when this was written, there are no practical cryptographic attacks against SHA-256, SHA-384, SHA-512, or HMAC. 😤 BUT, and this is a big but, the security also depends on how well the algorithm is implemented, how good your key management is, how strong your secret key is, and whether every participating system implements it correctly. These test vectors help you check that the algorithm is implemented correctly, but they do NOT verify the correctness (or security) of the rest of your security setup 💀
3.1. HMAC Key Length vs Truncation Length
okay this section is giving "the numbers matter" energy 🔢✨ There are real differences between the security levels of HMAC-SHA1-96 [HMAC-SHA1] and the HMAC-SHA-256+ algorithms, and some of them are kinda counter-intuitive 🙈 We measure security along two axes: the HMAC output length and the HMAC key length. If we assume the HMAC key is a well-guarded secret that can only be found through offline attacks on observed values, and its length is less than or equal to the output length of the underlying hash algorithm, then the key's strength is directly proportional to its length. And if we assume an attacker knows nothing about the HMAC key, then the chance of guessing a correct MAC value for any given packet is directly proportional to the HMAC output length.
This specification defines truncation to output lengths of either 128 192, or 256 bits. Now here's the plot twist 🫣 At this time, it is not clear that HMAC-SHA-256 with a truncation length of 128 bits is any more secure than HMAC-SHA1 with the same truncation length, assuming the attacker doesn't know the HMAC key. The reason is that the attacker only has to predict the bits left after truncation. Since both cases end up with the same output length (128 bits), the attacker's odds of correctly guessing the value are the same either way: 1 in 2^128. So if the HMAC key stays unknown to the attacker, only a bias in one of the algorithms would tell them apart. Right now, no such bias is known to exist in either HMAC-SHA1 or HMAC-SHA-256+ 🌸
If, on the other hand, the attacker is trying to guess the HMAC key, and we assume the hash algorithms are indistinguishable when viewed as PRF's, then the HMAC key length is a direct measure of the underlying security: the longer the key, the harder it is to guess. So with respect to passive attacks on the HMAC key, size matters, and the HMAC-SHA-256+ algorithms give you more security here than HMAC-SHA1-96 💪🍓
4. IANA Considerations 📋
okay so IANA's assignments are next 🧚 This document does not specify how to use SHA256+ for IKE Phase 1 negotiations, except to note that IANA has made the following IKE hash algorithm attribute assignments:
SHA2-256: 4
SHA2-384: 5
SHA2-512: 6For IKE Phase 2 negotiations, IANA has assigned the following authentication algorithm identifiers:
HMAC-SHA2-256: 5
HMAC-SHA2-384: 6
HMAC-SHA2-512: 7For use of HMAC-SHA-256+ as a PRF in IKEv2, IANA has assigned the following IKEv2 Pseudo-random function (type 2) transform identifiers:
PRF_HMAC_SHA2_256 5
PRF_HMAC_SHA2_384 6
PRF_HMAC_SHA2_512 7For the use of HMAC-SHA-256+ algorithms for data origin authentication and integrity verification in IKEv2, ESP, or AH, IANA has assigned the following IKEv2 integrity (type 3) transform identifiers:
AUTH_HMAC_SHA2_256_128 12
AUTH_HMAC_SHA2_384_192 13
AUTH_HMAC_SHA2_512_256 145. Acknowledgements ✨
Okay bestie, this section is the thank-you list 🫶 Parts of this text were unabashedly borrowed from [HMAC-SHA1] and [HMAC-TEST], no shame 💅 Huge thanks to Hugo Krawczyk for comments and recommendations on early revisions of this document! Also thanks to Russ Housley and Steve Bellovin for various security-related comments and recommendations. They're literally the reason this doc slaps 🔥
6. References 📚
6.1. Normative References
- [AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [HMAC-SHA1] Madsen, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
- [HMAC-TEST] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
- [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [SHA2-1] NIST, "FIPS PUB 180-2 'Specifications for the Secure Hash Standard'", 2004 FEB,
<http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf>. - [SHA256+] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
6.2. Informative References
- [SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512", 2001 MAY,
<http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>.
Authors' Addresses 💌
Scott G. Kelly
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
US
EMail: scott@hyperthought.com
Sheila Frankel
NIST
Bldg. 222 Room B264
Gaithersburg, MD 20899
US
EMail: sheila.frankel@nist.govFull Copyright Statement 📜
Here's the legal bit, and it's important, so read it 👀
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society! 💜
📦 where this page comes from
- ietf: rfc4868 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms