RFC 4894

RFC 4894: Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec 🎀

okay bestie, so the title block first 💅

• Author: P. Hoffman, VPN Consortium 🧚
• Category: Informational 📚
• Date: May 2007 🌸
• Obsoletes / Updates: the title block doesn't list anything here, so nothing is obsoleted or updated 🤷‍♀️

Status of This Memo ✨

this memo is here to give info to the Internet community 🫶 it does not specify an Internet standard of any kind, so don't go treating it like one 🙅‍♀️ and distribution is unlimited, so share away 🦋

Copyright Notice 💜

Copyright (C) The IETF Trust (2007).

Abstract 🌈

so this doc is all about how IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec use hash functions 🔥 it also explains how vulnerable these protocols are to the reduced collision resistance of the MD5 and SHA-1 hash algorithms 💀 (yes, MD5 and SHA-1 have been getting roasted lately, we'll get there).

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Hashes in IKEv1 and IKEv2  . . . . . . . . . . . . . . . . . .  2
3.  Hashes in IPsec  . . . . . . . . . . . . . . . . . . . . . . .  3
4.  PKIX Certificates in IKEv1 and IKEv2 . . . . . . . . . . . . .  3
5.  Choosing Cryptographic Functions . . . . . . . . . . . . . . .  3
  5.1.  Different Cryptographic Functions  . . . . . . . . . . . .  4
  5.2.  Specifying Cryptographic Functions in the Protocol . . . .  4
  5.3.  Specifying Cryptographic Functions in Authentication . . .  5
6.  Suggested Changes  . . . . . . . . . . . . . . . . . . . . . .  6
  6.1.  Suggested Changes for the Protocols  . . . . . . . . . . .  6
  6.2.  Suggested Changes for Implementors . . . . . . . . . . . .  7
7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
8.  Informative References . . . . . . . . . . . . . . . . . . . .  8
Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 10

1. Introduction 🦋

okay so the security crowd has recently found attacks on the collision-resistance properties of MD5 and SHA-1 hash functions 😭 [HashAttacks] has a summary of all the discoveries. Now everyone is re-checking how the various Internet protocols use hash functions 🔍 the goal is to make sure the current usage is still safe against these new attacks, and to figure out whether protocols can easily switch to new hash functions once those get recommended ✨

different protocols use hashes super differently, so the IETF asked for reviews of every protocol that uses them 💅 this document goes through the many ways three protocols use hash functions: IKEv1 [IKEv1], IKEv2 [IKEv2], and IPsec [ESP] and [AH] 🔥

quick terms check 🎀 in this doc, "IKEv1" only means "Phase 1" of IKEv1 and the agreement process. "IKEv2" means the IKE_SA_INIT and IKE_AUTH exchanges. "IPsec" means IP encapsulated in either the Authentication Header (AH) or Encapsulating Security Payload (ESP) 🧚

2. Hashes in IKEv1 and IKEv2 💖

both IKEv1 and IKEv2 can use hash functions as pseudo-random functions (PRFs) ✨ the inputs to the PRFs always include nonce values from both the initiator and the responder, and the other party can't predict those ahead of time 🔮 in IKEv1 the nonce is at least 64 bits, and in IKEv2 it's at least 128 bits 🌸 so, no cap, the hash use in IKEv1 and IKEv2 isn't vulnerable to any known collision-reduction attack 👑

IKEv1 also hashes the inputs to the PRF 🍓 those inputs are a mix of values from both the initiator and the responder, so the hash function here isn't vulnerable to any known collision-reduction attack either 💜

in IKEv2, hashes give integrity protection for all messages after the IKE_SA_INIT Exchange 🛡️ these hashes get used in Hashed Message Authentication Codes (HMACs). As [HMAC-reduction] explains, MD5 in HMACs is susceptible to forgery, and it's suspected that full SHA-1 in HMAC is susceptible to forgery too 😭 but there's no known reason for the person creating legit integrity protection to want to fake it 🙈

both IKEv1 and IKEv2 have authentication modes that use digital signatures ✍️ signatures use hashes to make unique digests of the message being signed 🦢 with the current known attacks, the only party that can create two colliding messages is the IKE entity that generates the message 🔒 [Target-collisions] shows that an attacker can make two different Public Key Infrastructure using X.509 (PKIX) certificates with different identities that have the same signatures 🫣

IKEv1 has two modes, "public key encryption" and "revised public key encryption", that use hashes to identify the public key being used 🎀 here the hash is just there to shrink the identifier 📏 in IKEv2 with public-key certificates, a hash function does a similar job, identifying both the sender's public key and the trust anchors 🧚 using a collision-reduction attack, someone could make two public keys with the same hash value 🤯 but it's not considered a useful attack, because the key generator holds both private keys 🔑

IKEv1 can be used together with Network Access Translator (NAT) traversal support, as described in [NAT-T]. IKEv2 includes this NAT traversal support built in 🌐 in both cases, hash functions are used to obscure the IP addresses used by the initiator and/or the responder 🙈 and the hash function here isn't vulnerable to any known collision-reduction attack 💅

3. Hashes in IPsec 🔐

AH uses hash functions to authenticate packets 📦 the same goes for ESP when ESP does its own authentication 💜 for both uses of IPsec, hashes are always used in HMACs ✨ as [HMAC-reduction] describes, MD5 in HMACs is susceptible to forgery, and full SHA-1 in HMAC is suspected to be susceptible to forgery too 😬 again, there's no known reason for someone creating legit packet authentication to want to spoof it 🫶

4. PKIX Certificates in IKEv1 and IKEv2 🎀

some implementations of IKEv1 and IKEv2 use PKIX certificates for authentication 🪪 any weaknesses in PKIX certificates, whether from particular ways hash functions are used or from weaknesses in particular hash functions used in certificates, will get inherited by IKEv1 and IKEv2 implementations that use PKIX-based authentication 💀 so the cert problems come along for the ride, bestie 🚗

5. Choosing Cryptographic Functions 👑

there's been more talk in the IETF lately about one party in a protocol telling the other party which cryptographic functions it would prefer them to use 🗣️ this discussion was partly sparked by [Deploying] 📄 even though that paper focuses on hash functions, the same ideas apply to other cryptographic functions too 🌈

there are (at least) three different subtopics for choosing cryptographic functions in protocols 🧩

• the ability to pick between different cryptographic functions, instead of having just one specified in the protocol 🍭
• if there are multiple functions, the ability to agree on which function will be used in the main protocol 🤝
• the ability to suggest to the other party which kinds of cryptographic functions should be used in the other party's public key certificates 📜

5.1. Different Cryptographic Functions 🦋

protocols that use cryptographic functions can either specify a single function or allow different functions 🔀 protocols in the first group are open to attack if the specified function turns out to be too weak for its purpose 💔 protocols in the second group can usually dodge those attacks, but it costs them extra protocol complexity 🧠 in the IETF, protocols that allow a choice of cryptographic functions are strongly preferred 💖

IKEv1, IKEv2, and IPsec already allow different hash functions in every significant place where hashes are used, meaning every place that's susceptible to a collision-reduction attack ✨

5.2. Specifying Cryptographic Functions in the Protocol 💜

protocols that allow a choice of cryptographic functions need a way for all parties to agree on which function will be used 🤝 some protocols, like secure electronic mail, let the initiator just pick a set of cryptographic functions 📨 if the responder doesn't understand the functions used, the transmission fails 💀 other protocols let the two parties agree on which cryptographic functions will be used 🫂 this is sometimes called "negotiation", but the term "negotiation" is a bad fit for protocols where one party (the "proposer") lists every function it's willing to use and the other party (the "chooser") just picks the ones that'll be used 🙅‍♀️

when a new cryptographic function shows up, one party might want to tell the other that it can use the new one 🆕 if the proposer is the one who wants the new function, it's easy: the proposer just adds it to its list, maybe removing other parallel functions it no longer wants to use 🧹

but if the chooser wants to use the new function and the proposer didn't list it, the chooser might want to tell the proposer it's capable of using the new function, or it might want to say it's only willing to use the new function 🤔 if a protocol wants to handle either of these cases, it needs a way for the chooser to pass that info back to the proposer in its acceptance and/or rejection message 📬

it's not clear from a design standpoint how important it is to let the chooser list the extra functions it knows 🤷‍♀️ as long as the proposer offers every function it wants to use, there's no reason for the chooser to say "I know one you don't know" 🙄 the only place the chooser can signal the proposer with different functions is in protocols where listing every function would be prohibitive, like where it would add extra round trips or a big packet length 📦

IKEv1 and IKEv2 let the proposer list all its functions 📋 neither one lets the chooser say which functions that weren't proposed it could have used, whether the Security Association (SA) establishment succeeds or fails 🙅‍♀️💅

Part 1 done, bestie 🌈 more parts coming, so stay tuned 💖

5.3. Specifying Cryptographic Functions in Authentication ✨

Okay, bestie, this is where it gets spicy 🌶️. Passing public key certificates and signatures for authentication creates extra issues for protocols. When you specify cryptographic functions for a protocol, it's an agreement between the proposer and the chooser 🤝. But for public key certificates, the proposer and the chooser are stuck with whatever functions the trusted third parties, the certification authorities (CAs), use 🙃. It doesn't really matter what either party wants the other to use, because the other party isn't the one issuing the certificates. Not me being powerless 💀.

Quick note on vocab: in this discussion, "certificate" doesn't necessarily mean a PKIX certificate 🦋. It means any message that binds an identity to a public key, as long as a trusted third party signed it. That can be non-PKIX certificates or other types of cryptographic identity-binding structures that might show up later 🔮.

The question of specifying cryptographic functions only matters if one party has multiple certificates or signatures using different cryptographic functions 🧐. Also, in this section, "proposer" and "chooser" mean something different than they did in the previous section, so don't get confused, babe 💜.

Here, both parties act as proposers of the identity they want to use, plus the certificates backing that identity up. And both parties are choosers of the other party's identity and certificate. Iconic mutual energy 👯‍♀️.

Some protocols let the proposer send multiple certificates or signatures, while others only let the proposer send a single one 🎀. Some protocols allow multiple certificates but advise against it, since certificates can be fairly large, especially when the CA stuffs them with lots of information 📦💀.

IKEv1 and IKEv2 let both parties list all the certificates they want to use 🫶. [PKI4IPsec] proposes restricting this by saying that all the certificates for a proposer have to have the same identity 🔒.

---

6. Suggested Changes 🛠️

Okay, so while the IETF was digging into how protocols use hash functions, it looked at (at least) two areas of possible changes 🔍. One is how the IETF might need to change the protocols. The other is how implementors of current protocols might change what they do 👩‍💻. This section covers both areas for IKEv1, IKEv2, and IPsec 💖.

6.1. Suggested Changes for the Protocols

Protocols might need changes if they rely on the collision-resistance of particular hash functions 😬. They might also need changes if they don't allow for agreeing on hash functions, because the "preferred" hash function for different users is expected to change over time 🔄.

IKEv1 and IKEv2 already allow agreeing on hash functions for both IKE and IPsec, so they don't need any protocol change ✅.

IKEv1 and IKEv2, when used with public key authentication, already let each party send multiple PKIX certificates, so again, no protocol change needed 🌸.

Now the tea ☕: there are known weaknesses in PKIX with respect to collision-resistance of some hash functions 🫠. Because of this, it's hoped that the PKIX Working Group will make changes to PKIX 🙏. Some of those changes might be usable in IKEv1 and IKEv2 without changing IKEv1 and IKEv2 at all ✨. Other PKIX changes may require changes to IKEv1 and IKEv2 to incorporate them, but we won't know that until the PKIX changes are finalized ⏳.

6.2. Suggested Changes for Implementors 👩‍🔬

As covered in earlier sections, IKE and IPsec themselves aren't susceptible to any known collision-reduction attacks on hash functions 🙌. So implementors don't need to do stuff like banning MD5 or SHA-1 🚫. The mandatory and suggested algorithms for IKEv2 and IPsec are given in [IKEv2Algs] and [IPsecAlgs] 📚.

Heads up, babe: some IKE and IPsec users will misunderstand how relevant the known attacks are and will want "stronger" hash functions 🚨. So implementors should strongly consider adding support for alternatives, especially the AES-XCBC-PRF-128 [AES-PRF] and AES-XCBC-MAC-96 [AES-MAC] algorithms, plus the forthcoming algorithms based on the SHA-2 family [SHA2-HMAC] 💅.

Implementations of IKEv1 and IKEv2 that use PKIX certificates for authentication may be susceptible to attacks based on weaknesses in PKIX 😱. It's widely expected that PKIX certificates will use hash functions other than MD5 and SHA-1 in the future 🔮. So implementors of IKE that allow certificate authentication should strongly consider allowing certificates signed with the SHA-256, SHA-384, and SHA-512 hash algorithms 🌈. Similarly, those implementors should also strongly consider allowing the sending of multiple certificates for identification 🆔.

---

7. Security Considerations 🚨

Real talk, this whole document is about the security implications of reduced collision-resistance of common hash algorithms for the IKE and IPsec protocols 🔐. It's literally the entire point, so pay attention 😤.

The Security Considerations section of [HashAttacks] goes way deeper into the security of hash functions 🕵️‍♀️. Go read it if you want the full tea ☕.

8. Informative References 📖

Here's the reading list, every single one, so you can go full nerd on it 🤓:

[AES-MAC]            Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
                     Algorithm and Its Use With IPsec", RFC 3566,
                     September 2003.

[AES-PRF]            Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for
                     the Internet Key Exchange Protocol (IKE)",
                     RFC 4434, February 2006.

[AH]                 Kent, S., "IP Authentication Header", RFC 4302,
                     December 2005.

[Deploying]          Bellovin, S. and E. Rescorla, "Deploying a New
                     Hash Algorithm", NDSS '06, February 2006.

[ESP]                Kent, S., "IP Encapsulating Security Payload
                     (ESP)", RFC 4303, December 2005.

[HashAttacks]        Hoffman, P. and B. Schneier, "Attacks on
                     Cryptographic Hashes in Internet Protocols",
                     RFC 4270, November 2005.

[HMAC-reduction]     Contini, S. and YL. Yin, "Forgery and Partial
                     Key-Recovery Attacks on HMAC and NMAC Using Hash
                     Collisions", Cryptology ePrint Report 2006/319,
                     September 2006.

[IKEv1]              Harkins, D. and D. Carrel, "The Internet Key
                     Exchange (IKE)", RFC 2409, November 1998.

[IKEv2]              Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
                     Protocol", RFC 4306, December 2005.

[IKEv2Algs]          Schiller, J., "Cryptographic Algorithms for use
                     in the Internet Key Exchange Version 2",
                     RFC 4307, December 2005.

[IPsecAlgs]          Eastlake, D., "Cryptographic Algorithm
                     Implementation Requirements For ESP And AH",
                     RFC 4305, December 2005.

[NAT-T]              Kivinen, T., Swander, B., Huttunen, A., and V.
                     Volpe, "Negotiation of NAT-Traversal in the
                     IKE", RFC 3947, January 2005.

[PKI4IPsec]          Korver, B., "The Internet IP Security PKI
                     Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work
                     in Progress, April 2007.

[SHA2-HMAC]          Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
                     HMAC-SHA-384, and HMAC-SHA-512 With IPsec",
                     RFC 4868, May 2007.

[Target-collisions]  Stevens, M., Lenstra, A., and B. de Weger,
                     "Target Collisions for MD5 and Colliding X.509
                     Certificates for Different Identities",
                     Cryptology ePrint Report 2006/360, October 2006.

Appendix A. Acknowledgments 💜

Huge thanks to Tero Kivinen, who helped with ideas in the first version of this document 🫶. Many participants on the SAAG and IPsec mailing lists contributed ideas in later versions 🌷. In particular, suggestions came from Alfred Hoenes, Michael Richardson, Hugo Krawczyk, Steve Bellovin, David McGrew, Russ Housley, Arjen Lenstra, and Pasi Eronen 👑✨.

Author's Address 🎀

Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA  95060
US

EMail: paul.hoffman@vpnc.org

Full Copyright Statement ©️

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights 🔏.

This document and the information in it are provided on an "AS IS" basis. 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 on 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. It also takes no position on whether any license under such rights might or might not be available, and it doesn't claim to have made any independent effort to identify such rights 🕵️. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📜.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the result of any attempt to obtain a general license or permission for implementers or users to use such proprietary rights can be found in the IETF online 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 required to implement this standard 💌. Please send that information to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society 💖.