diff options
Diffstat (limited to 'doc/rfc/rfc4894.txt')
| -rw-r--r-- | doc/rfc/rfc4894.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc4894.txt b/doc/rfc/rfc4894.txt new file mode 100644 index 0000000..0f2f622 --- /dev/null +++ b/doc/rfc/rfc4894.txt @@ -0,0 +1,619 @@ + + + + + + +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). + +Abstract + + This 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. + +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 + + + + + + + + + + + +Hoffman Informational [Page 1] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + +1. Introduction + + Recently, attacks on the collision-resistance properties of MD5 and + SHA-1 hash functions have been discovered; [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). + +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 contain nonce values + from both the initiator and the responder that the other party cannot + predict in advance. In IKEv1, the length of this nonce is at least + 64 bits; in IKEv2, it is at least 128 bits. Because of this, the use + of hash functions in IKEv1 and IKEv2 are not susceptible to any known + collision-reduction attack. + + IKEv1 also uses hash functions on the inputs to the PRF. The inputs + are a combination of values from both the initiator and responder, + and thus the hash function here is not susceptible to any known + collision-reduction attack. + + In IKEv2, hashes are used as integrity protection for all messages + after the IKE_SA_INIT Exchange. These hashes are used in Hashed + Message Authentication Codes (HMACs). As described in + [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 + + + +Hoffman Informational [Page 2] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + + 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. + +3. Hashes in IPsec + + AH uses hash functions for authenticating packets; the same is true + for ESP when ESP is using its own authentication. For both uses of + IPsec, hash functions are always used in hashed MACs (HMACs). As + described in [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. + +4. PKIX Certificates in IKEv1 and IKEv2 + + Some implementations of IKEv1 and IKEv2 use PKIX certificates for + authentication. Any weaknesses in PKIX certificates due to + particular ways hash functions are used, or due to weaknesses in + particular hash functions used in certificates, will be inherited in + IKEv1 and IKEv2 implementations that use PKIX-based authentication. + +5. Choosing Cryptographic Functions + + Recently, there has been more discussion in the IETF about the + ability of one party in a protocol to tell the other party which + cryptographic functions the first party prefers the second party to + use. The discussion was spurred in part by [Deploying]. Although + that paper focuses on hash functions, it is relevant to other + cryptographic functions as well. + + + +Hoffman Informational [Page 3] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + + 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 + +5.1. Different Cryptographic Functions + + Protocols that use cryptographic functions can either specify a + single function, or can allow different functions. Protocols in the + first category are susceptible to attack if the specified function is + later found to be too weak for the stated purpose; protocols in the + second category can usually avoid such attacks, but at a cost of + increased 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 hash functions are used (that is, in + every place that has any susceptibility to a collision-reduction + attack). + +5.2. Specifying Cryptographic Functions in the Protocol + + Protocols that allow a choice of cryptographic functions need to have + a way for all parties to agree on which function is going to be used. + Some protocols, such as secure electronic mail, allow the initiator + to simply pick a set of cryptographic functions; if the responder + does not understand the functions used, the transmission fails. + Other protocols allow for the two parties to agree on which + cryptographic functions will be used. This is sometimes called + "negotiation", but the term "negotiation" is inappropriate for + protocols in which one party (the "proposer") lists all the functions + it is willing to use, and the other party (the "chooser") simply + picks the ones that will be used. + + When a new cryptographic function is introduced, one party may want + to tell the other party that they can use the new function. If it is + the proposer who wants to use the new function, the situation is + easy: the proposer simply adds the new function to its list, possibly + + + + + +Hoffman Informational [Page 4] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + + 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. + +5.3. Specifying Cryptographic Functions in Authentication + + Passing public key certificates and signatures used in authentication + creates additional issues for protocols. When specifying + cryptographic functions for a protocol, it is an agreement between + the proposer and the chooser. When choosing cryptographic functions + for public key certificates, however, the proposer and the chooser + are beholden to functions used by the trusted third parties, the + certification authorities (CAs). It doesn't really matter what + either party wants the other party to use, since the other party is + not the one issuing the certificates. + + In this discussion, the term "certificate" does not necessarily mean + a PKIX certificate. Instead, it means any message that binds an + identity to a public key, where the message is signed by a trusted + third party. This can be non-PKIX certificates or other types of + cryptographic identity-binding structures that may be used in the + future. + + The question of specifying cryptographic functions is only relevant + if one party has multiple certificates or signatures with different + cryptographic functions. In this section, the terms "proposer" and + "chooser" have a different meaning than in the previous section. + + + +Hoffman Informational [Page 5] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + + 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. + +6. Suggested Changes + + In investigating how protocols use hash functions, the IETF is + looking at (at least) two areas of possible changes to individual + protocols: how the IETF might need to change the protocols, and how + implementors of current protocols might change what they do. This + section describes both of these areas with respect to IKEv1, IKEv2, + and IPsec. + +6.1. Suggested Changes for the Protocols + + Protocols might need to be changed if they rely on the collision- + resistance of particular hash functions. They might also need to be + changed if they do not allow for the agreement of hash functions + because it is expected that the "preferred" hash function for + different users will change over time. + + IKEv1 and IKEv2 already allow for the agreement of hash functions for + both IKE and IPsec, and thus do not need any protocol change. + + IKEv1 and IKEv2, when used with public key authentication, already + allow each party to send multiple PKIX certificates, and thus do not + need any protocol change. + + There are known weaknesses in PKIX with respect to collision- + resistance of some hash functions. Because of this, it is hoped that + there will be changes to PKIX fostered by the PKIX Working Group. + Some of the changes to PKIX may be usable in IKEv1 and IKEv2 without + having to change IKEv1 and IKEv2. Other changes to PKIX may require + changes to IKEv1 and IKEv2 in order to incorporate them, but that + will not be known until the changes to PKIX are finalized. + + + +Hoffman Informational [Page 6] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + +6.2. Suggested Changes for Implementors + + As described in earlier sections, IKE and IPsec themselves are not + susceptible to any known collision-reduction attacks on hash + functions. Thus, implementors do not need to make changes such as + prohibiting the use of MD5 or SHA-1. The mandatory and suggested + algorithms for IKEv2 and IPsec are given in [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. + +7. Security Considerations + + This entire document is about the security implications of reduced + collision-resistance of common hash algorithms for the IKE and IPsec + protocols. + + The Security Considerations section of [HashAttacks] gives much more + detail about the security of hash functions. + + + + + + + + + + + + + + + + + +Hoffman Informational [Page 7] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + +8. Informative References + + [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. + + + + + + +Hoffman Informational [Page 8] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoffman Informational [Page 9] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + +Appendix A. Acknowledgments + + Tero Kivinen 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 were made by + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoffman Informational [Page 10] + +RFC 4894 IKE and IPsec Hash Use May 2007 + + +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 + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Hoffman Informational [Page 11] + |