RFC 5926
Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
RFC 5926 📜🎀
Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) 💖
Okay bestie, the header info first ✨. This is from the IETF (Internet Engineering Task Force), and the authors are G. Lebovitz (Juniper) and E. Rescorla (RTFM). It's a Standards Track doc, ISSN 2070-1721, dated June 2010. The header doesn't list any Obsoletes or Updates entries, so it doesn't replace or change any earlier RFC 🧚.
Abstract ✨
TCP-AO leans on security algorithms to give authentication between two end-points 🔐. There are a bunch of these algorithms out there, and two TCP-AO systems can't interoperate unless they're using the same ones 😭. This doc lays out the algorithms and attributes you can use in TCP-AO's current manual keying mechanism, and it sets up the interface for future message authentication codes (MACs) 🦋.
Status of This Memo 🌸
This is an Internet Standards Track document.
This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). You can find more about Internet Standards in Section 2 of RFC 5741 📚.
For info on the current status of this document, any errata, and how to send feedback, check out http://www.rfc-editor.org/info/rfc5926 💻.
Copyright Notice 💅
Copyright (c) 2010 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/license-info) as they were in effect on the date this doc was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚖️.
Table of Contents 🗺️
1. Introduction ....................................................2
2. Requirements ....................................................3
2.1. Requirements Language ......................................3
2.2. Algorithm Requirements .....................................3
2.3. Requirements for Future MAC Algorithms .....................3
3. Algorithms Specified ............................................4
3.1. Key Derivation Functions (KDFs) ............................4
3.1.1. Concrete KDFs .......................................5
3.1.1.1. KDF_HMAC_SHA1 ..............................6
3.1.1.2. KDF_AES_128_CMAC ...........................7
3.1.1.3. Tips for User Interfaces Regarding KDFs ....9
3.2. MAC Algorithms .............................................9
3.2.1. The Use of HMAC-SHA-1-96 ...........................10
3.2.2. The Use of AES-128-CMAC-96 .........................11
4. Security Considerations ........................................11
5. IANA Considerations ............................................13
6. Acknowledgements ...............................................13
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................141. Introduction 🎀
This doc is a companion to [RFC5925]. Like most modern security protocols, TCP-AO lets users choose which cryptographic algorithm(s) they want to use to meet their security needs 💖.
TCP-AO gives you cryptographic authentication and message integrity verification between two end-points 🛡️. To pull this off, it uses message authentication codes (MACs), which rely on shared keys 🔑. There are a few different ways to make MACs. The use of hash-based MACs (HMACs) is defined in [RFC2104]. The use of cipher-based MACs (CMACs) is defined in [NIST-SP800-38B] ✨.
This RFC sets the general requirements for MACs used in TCP-AO, both for the ones currently specified and for any future ones 🔮. It specifies two MAC algorithms that are required in all TCP-AO implementations. It also specifies two key derivation functions (KDFs) that create the traffic keys the MACs use, and those KDFs are required by all TCP-AO implementations too 🌈.
2. Requirements 💜
2.1. Requirements Language 🧠
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When they're in lowercase, these words mean what they normally mean in everyday language, and they are not to be interpreted as described in [RFC2119] 🙈.
2.2. Algorithm Requirements 🔐
This is the first spec for required cryptography in TCP-AO. It names two MAC algorithms and two KDFs. All four components MUST be implemented for an implementation to be fully compliant with this RFC 💅.
Here's the table of required MAC algorithms and KDFs for TCP-AO:
Requirement Authentication Algorithm
------------ ------------------------
MUST HMAC-SHA-1-96 [RFC2104][FIPS-180-3]
MUST AES-128-CMAC-96 [NIST-SP800-38B][FIPS197]
Requirement Key Derivation Function (KDF)
------------- ------------------------
MUST KDF_HMAC_SHA1
MUST KDF_AES_128_CMACFor an explanation of why two MAC algorithms got mandated, see Section 4 🧐.
2.3. Requirements for Future MAC Algorithms 🔮
TCP-AO is meant to support cryptographic agility, so this doc includes recommendations in various places for future MAC and KDF algorithms used with TCP-AO 🦋. For future MAC algorithms specifically, they SHOULD protect at least 2**48 messages with a collision probability of less than one in 10**9 ⭐.
3. Algorithms Specified 🧚
TCP-AO needs two classes of cryptographic algorithms for a particular connection, and it refers to this document to define both of them:
- (1) Key Derivation Functions (KDFs), which name a pseudorandom function (PRF) and use a Master_Key plus some connection-specific input with that PRF to produce Traffic_Keys. Those are the keys for authenticating and integrity checking individual TCP segments, as described in TCP-AO 🔑.
- (2) Message Authentication Code (MAC) algorithms, which take a key and a message and produce an authentication tag. That tag can be used to verify the integrity and authenticity of those messages ✅.
In TCP-AO, these algorithms are always used in pairs. Each MAC algorithm MUST specify the KDF to be used with it. However, a KDF MAY be used with more than one MAC algorithm 👯.
3.1. Key Derivation Functions (KDFs) 🗝️
TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP-AO's current manual keying have the following interface:
Traffic_Key = KDF_alg(Master_Key, Context, Output_Length)where:
KDF_alg: the specific pseudorandom function (PRF) that's the basic building block used to construct the given Traffic_Key 🧱.Master_Key: In TCP-AO's manual key mode, this is a key shared by both peers, entered through some interface into their respective configurations. The Master_Key is used as the seed for the KDF. We assume it's a human-readable pre-shared key (PSK), so it's of variable length 📝. Master_Keys SHOULD be random, but they might not be (for example, if the user picked a bad one 💀). For interoperability, the management interface used to configure the PSK MUST accept ASCII strings, and it SHOULD also allow configuring any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported 🎛️.Context: A binary string with info about the specific connection for this derived keying material, as defined in [RFC5925], Section 5.2 🌸.Output_Length: The length, in bits, of the key the KDF will produce. This length must be the size required for the MAC algorithm that will use the PRF result as a seed 📏.
When it's invoked, a KDF generates a string of length Output_Length bits based on the Master_Key and context value. That result may then be used as a cryptographic key for any algorithm that takes a key of Output_Length length 🎉. A KDF MAY specify a maximum Output_Length parameter 💜.
3.1.1. Concrete KDFs ✨
okay so there are two KDF algorithms in this doc, and each one is paired with its own PRF (the pseudorandom function that does the heavy lifting) 💅
KDF_HMAC_SHA1 is based on PRF-HMAC-SHA1 [RFC2104][FIPS-180-3] 🌸
KDF_AES_128_CMAC is based on AES-CMAC-PRF-128 [NIST-SP800-38B][FIPS197] 🦋
Both of these are built on the iteration-mode KDFs from [NIST-SP800-108] ✨ So they use a PRF with a fixed-length output: 128 bits for AES-CMAC and 160 bits for HMAC-SHA1. To get as many output bits as you want, the KDF runs the PRF in a "counter mode," where every call gets a different input block, told apart by a block counter. It's giving clever, ngl 🧚
Each input block is built like this:
( i || Label || Context || Output_Length )Where:
- "||": For any X || Y, "||" means you concatenate the binary strings X and Y. 🎀
- i: A counter. It's a binary string that goes into every PRF iteration in counter mode. The counter "i" is one octet. How many iterations you get depends on how big the Output_Length is for a given MAC. "i" always starts at 1. 🔢
- Label: A binary string that clearly says what this KDF's derived keying material is for. For TCP-AO, the label is the ASCII string "TCP-AO", and the last character is the capital letter "O", NOT a zero. 🙈 Yes, it might feel like overkill since TCP-AO only calls the KDF once, but it's included so it can comply with FIPS 140 certifications. 💜
- Context: The context argument given to the KDF interface, as described above in Section 3.1 . ✨
- Output_Length: The length, in bits, of the key the KDF will produce. It's represented in two octets. This length has to be the size the MAC algorithm that uses the PRF result as a seed needs. 🍓
The output from multiple PRF invocations is just concatenated 🫶 For the Traffic_Key, the values from several PRF invocations get concatenated and then truncated as needed to make a Traffic_Key of the length you want. For example, if you're using KDF_HMAC_SHA1, which has a 160-bit internal PRF and makes 320 bits of data, you run the PRF twice: once with i=1 and once with i=2. The result is the whole output of the first invocation, concatenated with the second one. Like this:
Traffic_Key =
KDF_alg(Master_Key, 1 || Label || Context || Output_length) ||
KDF_alg(Master_Key, 2 || Label || Context || Output_length)If the number of bits you need isn't an exact multiple of the PRF's output size, the output of the final invocation gets truncated to fit 🌈
3.1.1.1. KDF_HMAC_SHA1
For KDF_HMAC_SHA1:
- PRF for KDF_alg: HMAC-SHA1 [RFC2104][FIPS-180-3]. 🌸
- Use: HMAC-SHA1(Key, Input).
- Key: Master_Key, configured by the user and passed to the KDF.
- Input: ( i || Label || Context || Output_Length)
- Output_Length: 160 bits.
- Result: Traffic_Key, used in the MAC function by TCP-AO.
3.1.1.2. KDF_AES_128_CMAC
For KDF_AES_128_CMAC:
- PRF for KDF_alg: AES-CMAC-PRF-128 [NIST-SP800-38B][FIPS197].
- Use: AES-CMAC(Key, Input).
- Key: Master_Key (see usage below)
- Input: ( i || Label || Context || Output_Length)
- Output_Length: 128 bits.
- Result: Traffic_Key, used in the MAC function by TCP-AO
Okay, this part is a bit of a plot twist 🙃 In TCP-AO's current manual keying mechanism, the Master_Key is a shared secret that an administrator types in. It gets passed out-of-band between two devices, and often between two organizations. The shared secret doesn't have to be 16 octets, and its length can vary. BUT AES_128_CMAC needs a key of exactly 16 octets (128 bits) 😭 We could make implementations force admins to type in exactly 128-bit Master_Keys when using AES_128_CMAC, with enough randomness, but that's a lot of work for the implementors and deployers. So this specification RECOMMENDS that deployers use a randomly generated 128-bit string as the Master_Key, while acknowledging that deployers may not. 💅
To handle variable-length Master_Keys, we use the same mechanism as described in [RFC4615], Section 3. It goes like this 🧠 First, we run AES_128_CMAC with a fixed key of all zeros as a "randomness extractor," using the shared secret Master_Key, MK, as the message input. That gives us a 128-bit key called Derived_Master_Key (K). Second, we take that result, use it as a key, and run AES-128_CMAC again. This time, K is the Key and the true input block is the Input, and that gives us the Traffic_Key (TK) used in the MAC over the message. Here's the whole thing:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ KDF-AES-128-CMAC +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Input : MK (Master_Key, the variable-length shared secret) +
+ : I (Input, i.e., the input data of the PRF) +
+ : MKlen (length of MK in octets) +
+ : len (length of M in octets) +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) +
+ +
+-------------------------------------------------------------------+
+ Variable: K (128-bit key for AES-CMAC) +
+ +
+ Step 1. If MKlen is equal to 16 +
+ Step 1a. then +
+ K := MK; +
+ Step 1b. else +
+ K := AES-CMAC(0^128, MK, MKlen); +
+ Step 2. TK := AES-CMAC(K, I, len); +
+ return TK; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Figure 1
Step 1 is where K, the 128-bit key for AES-CMAC, gets derived 🔑 Here's how:
- If the Master_Key, MK, the administrator gave us is exactly 128 bits, we just use it as is. 🎀
- If it's longer or shorter than 128 bits, we derive K by running AES-CMAC with the 128-bit all-zero string as the key and MK as the input message. That's step 1b. 🌙
In step 2, we run AES-CMAC again, this time with K as the key and I as the input message ✨
The output of this algorithm is TK, the Traffic_Key. It's 128 bits and it's ready to use in the MAC function on each TCP segment of the connection 🦋
3.1.1.3. Tips for User Interfaces Regarding KDFs
This section gives suggested names for the KDFs in implementation user interfaces (UIs) 💖 Following these guidelines across common implementations makes interoperability easier and simpler for deployers. 🫶
UIs SHOULD refer to KDF_HMAC_SHA1 as simply "SHA1". 🌸
UIs SHOULD refer to KDF_AES_128_CMAC as simply "AES128". 🦋
The initial IANA registry values reflect these two entries 📋
UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO settings. KDF_HMAC_SHA1 is preferred right now because it has wide support, since it's in most implementations out in the marketplace. 👑
3.2. MAC Algorithms
Each MAC_alg defined for TCP-AO has three fixed elements as part of its definition:
- KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the Traffic_Key.
- Key_Length: Length, in bits, required for the Traffic_Key used in this MAC.
- MAC_Length: The final length of the bits used in the TCP-AO MAC field. This value may be a truncation of the MAC function's original output length.
MACs computed for TCP-AO have the following interface:
MAC = MAC_alg(Traffic_Key, Message)where:
- MAC_alg: MAC Algorithm used.
- Traffic_Key: Variable; the result of KDF.
- Message: The message to be authenticated, as specified in [RFC5925], Section 5.1.
This document specifies two MAC algorithm options for generating the MAC used by TCP-AO:
- HMAC-SHA-1-96 based on [RFC2104] and [FIPS-180-3].
- AES-128-CMAC-96 based on [NIST-SP800-38B][FIPS197]
Both give a high level of security and efficiency ✨ AES-128-CMAC-96 is potentially more efficient, especially in hardware. But HMAC-SHA-1-96 is more widely used in Internet protocols, and in most cases it could be supported with little or no extra code in today's deployed software and devices 💅
Something important to know about these algorithms for TCP-AO is that the MAC outputs get truncated to 96 bits 👀 AES-128-CMAC-96 produces a 128-bit MAC, and HMAC SHA-1 produces a 160-bit result. The MAC output is then truncated to 96 bits to get a reasonable trade-off between security and message size, so it fits in the TCP-AO option field. 🎀
3.2.1. The Use of HMAC-SHA-1-96
By definition, HMAC [RFC2104] requires a cryptographic hash function. SHA1 is the hash function that'll be used for authenticating and providing integrity validation on TCP segments with HMAC 🌸
The three fixed elements for HMAC-SHA-1-96 are:
- KDF_Alg: KDF_HMAC_SHA1.
- Key_Length: 160 bits.
- MAC_Length: 96 bits.
For:
MAC = MAC_alg (Traffic_Key, Message)HMAC-SHA-1-96 for TCP-AO has the following values:
- MAC_alg: HMAC-SHA1.
- Traffic_Key: Variable; the result of the KDF.
- Message: The message to be authenticated, as specified in [RFC5925], Section 5.1.
3.2.2. The Use of AES-128-CMAC-96
In the context of TCP-AO, when we say "AES-128-CMAC-96," we're actually defining a usage of AES-128 as a cipher-based MAC according to [NIST-SP800-38B] 🦋
The three fixed elements for AES-128-CMAC-96 are:
- KDF_Alg: KDF_AES_128_CMAC.
- Key_Length: 128 bits.
- MAC_Length: 96 bits.
For:
MAC = MAC_alg (Traffic_Key, Message)AES-128-CMAC-96 for TCP-AO has the following values:
- MAC_alg: AES-128-CMAC-96. [NIST-SP800-38B]
- Traffic_Key: Variable; the result of the KDF.
- Message: The message to be authenticated, as specified in [RFC5925], Section 5.1.
4. Security Considerations 🔐✨
Okay bestie, this is the security section and it is SERIOUS 💀, so pay attention. This document inherits all of the security considerations of the TCP-AO [RFC5925], the AES-CMAC [RFC4493], and the HMAC-SHA-1 [RFC2104] documents. It gets all the drama from those specs too 🫶.
The security of cryptography-based systems depends on two things: how strong the cryptographic algorithms are and how strong the keys are. The security also depends on how the protocol is engineered, so there are no non-cryptographic ways to get around the security of the whole system 🔒.
Care should also be taken to make sure the selected key is unpredictable, and to avoid any keys that are known to be weak for the algorithm in use. [RFC4086] has helpful info on both key generation techniques and cryptographic randomness 🌸.
Now, the KDF situation 👀. When you compose KDF_AES_128_CMAC, the PRF needs a 128-bit / 16-byte key as the seed. BUT, for the convenience of the administrators and deployers, we did not want to force them to type in a 16-byte Master_Key. So we specified a sub-key routine that can handle a variable-length Master_Key, one that might be less than 16 bytes. Lowkey genius, right? 🧚
This does not mean that it is safe for administrators to use weak keys 🚨. Administrators are encouraged to follow [RFC4086], as listed above. We simply attempted to "put a fence around foolishness", as much as possible 🍓.
This document is all about picking the cryptographic algorithms for using TCP-AO 🦋. The algorithms identified in this document as "MUST implement" are not known to be broken right now, and cryptographic research so far leads us to believe that they will likely stay secure into the foreseeable future 💜. Some of the algorithms may turn out to have properties that are way weaker than what people believed when this document was written 😭. New revisions of this document will be issued from time to time, so expect that, and be sure to search for more recent versions of this document before you implement ✨.
Note explaining why two MAC algorithms were mandated:
Two MAC algorithms and two corresponding KDFs are mandated as a result of discussion in the TCPM WG, and in consultation with the Security Area Directors 👑. SHA-1 was selected because it is widely deployed and currently has sufficient strength and reasonable computational cost, so it is a "MUST" for TCP-AO today 💅. The security strength of SHA-1 HMACs should be sufficient for the foreseeable future, especially given that the tags are truncated to 96 bits 🎀.
Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC MD5) aren't practical on HMAC-SHA-1, but these types of analyses keep piling up and could potentially pose a concern for HMAC forgery if they were significantly improved over time 👀. The security issues driving the migration from SHA-1 to SHA-256 for digital signatures [HMAC-ATTACK] do not immediately make SHA-1 weak for this application of SHA-1 in HMAC mode 🌈.
AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but it may not have very wide implementation yet 🦋. AES-128 CMAC is also a "MUST" to implement, in order to push vendors toward using it, and to give us another MAC option if SHA-1 were ever compromised 🫶💖.
5. IANA Considerations 🗂️
IANA has created the following registry (http://www.iana.org) 🌸.
Registry Name: Cryptographic Algorithms for TCP-AO Registration
Procedure: RFC Publication after Expert ReviewInitial contents of this registry are:
Algorithm | Reference
----------------|-----------
SHA1 | [RFC5926]
AES128 | [RFC5926]6. Acknowledgements 🙌
Eric "EKR" Rescorla, who gave a TON of input and feedback 💅, including a somewhat heavy re-write of Section 3.1.x, which earned him an author slot on the document 👑.
Paul Hoffman, from whose [RFC4308] I sometimes copied 🙈, to quickly create a first version here.
Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two hash algorithms for TCP-AO is largely cut-and-pasted into various sections of this document 📧.
Jeff Schiller, Donald Eastlake, and the IPsec WG, whose [RFC4307] & [RFC4835] text was consulted and sometimes used in the Requirements Section 2 of this document 🧠.
(In other words, I was truly only an editor of others' text in creating this document 😭🫶.)
Eric "EKR" Rescorla and Brian Weis, who brought clarity to the issues with the inputs to PRFs for the KDFs ✨. EKR was also a huge help with how to structure the text, and with guiding good cryptographic decisions 🦋.
The TCPM working group, who put up with all us crypto and routing folks DoS'ing their WG for 2 years 💀, and who provided reviews of this document 💜.
7. References 📚
7.1. Normative References
[FIPS-180-3] FIPS Publication 180-3, "Secured Hash Standard",
FIPS 180-3, October 2008.
[FIPS197] FIPS Publications 197, "Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[NIST-SP800-108]
National Institute of Standards and Technology,
"Recommendation for Key Derivation Using Pseudorandom
Functions, NIST SP800-108", SP 800- 108, October 2009.
[NIST-SP800-38B]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
The CMAC Mode for Authentication", SP 800-38B,
May 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, June 2006.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.7.2. Informative References
[HMAC-ATTACK] "On the Security of HMAC and NMAC Based on HAVAL, MD4,
MD5, SHA-0 and SHA-1", <http://
www.springerlink.com/content/00w4v62651001303> , 2006,
<http://eprint.iacr.org/2006/187>.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec",
RFC 4308, December 2005.
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128
(AES-CMAC-PRF-128) Algorithm for the Internet Key
Exchange Protocol (IKE)", RFC 4615, August 2006.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)", RFC 4835, April 2007.Authors' Addresses 🖊️
Gregory Lebovitz
Juniper Networks, Inc.
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
US
Phone:
EMail: gregory.ietf@gmail.com
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
US
Phone: 650-678-2350
EMail: ekr@rtfm.com📦 where this page comes from
- ietf: rfc5926 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms