Network Working Group P. Hoffman Request for Comments: 4894 VPN Consortium Category: Informational May 2007 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. 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
HashAttacks] summarizes the discoveries. The security community is now reexamining how various Internet protocols use hash functions. The goal of this reexamination is to be sure that the current usage is safe in the face of these new attacks, and whether protocols can easily use new hash functions when they become recommended. Different protocols use hash functions quite differently. Because of this, the IETF has asked for reviews of all protocols that use hash functions. This document reviews the many ways that three protocols (IKEv1 [IKEv1], IKEv2 [IKEv2], and IPsec [ESP] and [AH]) use hash functions. In this document, "IKEv1" refers to only "Phase 1" of IKEv1 and the agreement process. "IKEv2" refers to the IKE_SA_INIT and IKE_AUTH exchanges. "IPsec" refers to IP encapsulated in either the Authentication Header (AH) or Encapsulating Security Payload (ESP). HMAC-reduction], MD5 used in HMACs is susceptible to forgery, and it is suspected that full SHA-1 used in HMAC is susceptible to forgery. There is no known reason for the person who creates legitimate integrity protection to want to spoof it. Both IKEv1 and IKEv2 have authentication modes that use digital signatures. Digital signatures use hashes to make unique digests of the message being signed. With the current known attacks, the only party that can create the two messages that collide is the IKE entity
that generates the message. As shown in [Target-collisions], an attacker can create 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 used. The hash function here is used simply to reduce the size of the identifier. In IKEv2 with public-key certificates, a hash function is used for similar purposes, both for identifying the sender's public key and the trust anchors. Using a collision-reduction attack, an individual could create two public keys that have the same hash value. This is not considered to be 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. In both of these cases, hash functions are used to obscure the IP addresses used by the initiator and/or the responder. The hash function here is not susceptible to any known collision-reduction attack. HMAC-reduction], MD5 used in HMACs is susceptible to forgery, and it is suspected that full SHA-1 used in HMAC is susceptible to forgery. There is no known reason for the person who creates legitimate packet authentication to want to spoof it. Deploying]. Although that paper focuses on hash functions, it is relevant to other cryptographic functions as well.
There are (at least) three distinct subtopics related to choosing cryptographic functions in protocols: o The ability to pick between different cryptographic functions instead of having just one specified in the protocol o If there are multiple functions, the ability to agree on which function will be used in the main protocol o The ability to suggest to the other party which kinds of cryptographic functions should be used in the other party's public key certificates
removing other parallel functions that the proposer no longer wants to use. On the other hand, if it is the chooser who wants to use the new function and the proposer didn't list it, the chooser may want to signal the proposer that they are capable of using the new function or the chooser may want to say that it is only willing to use the new function. If a protocol wants to handle either of these cases, it has to have a way for the chooser to specify this information to the proposer in its acceptance and/or rejection message. It is not clear from a design standpoint how important it might be to let the chooser specify the additional functions it knows. As long as the proposer offers all the functions it wants to use, there is no reason for the chooser to say "I know one you don't know". The only place where the chooser is able to signal the proposer with different functions is in protocols where listing all the functions might be prohibitive, such as where they would add additional round trips or significant packet length. IKEv1 and IKEv2 allow the proposer to list all functions. Neither allows the chooser to specify which functions that were not proposed it could have used, either in a successful or unsuccessful Security Association (SA) establishment.
Here, both parties act as proposers of the identity they want to use and the certificates with which they are backing up that identity, and both parties are choosers of the other party's identity and certificate. Some protocols allow the proposer to send multiple certificates or signatures, while other protocols only allow the proposer to send a single certificate or signature. Some protocols allow the proposer to send multiple certificates but advise against it, given that certificates can be fairly large (particularly when the CA loads the certificate with lots of information). IKEv1 and IKEv2 allow both parties to list all the certificates that they want to use. [PKI4IPsec] proposes to restrict this by saying that all the certificates for a proposer have to have the same identity.
IKEv2Algs] and [IPsecAlgs]. Note that some IKE and IPsec users will misunderstand the relevance of the known attacks and want to use "stronger" hash functions. Thus, implementors should strongly consider adding support for alternatives, particularly the AES-XCBC-PRF-128 [AES-PRF] and AES- XCBC-MAC-96 [AES-MAC] algorithms, as well as 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 is widely expected that PKIX certificates in the future will use hash functions other than MD5 and SHA-1. Implementors of IKE that allow certificate authentication should strongly consider allowing the use of certificates that are 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. HashAttacks] gives much more detail about the security of hash functions.
[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.
Full Copyright Statement 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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.