Network Working Group P. Hoffman Internet-Draft VPN Consortium Expires: May 27, 2006 November 23, 2005 Use of Hash Algorithms in IKE and IPsec draft-hoffman-ike-ipsec-hash-use-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes how the IKEv1, 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 Recently, attacks on the collision-resistance properties MD5 and Hoffman Expires May 27, 2006 [Page 1] Internet-Draft IKE and IPsec Hash Use November 2005 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 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 negotiating process. "IKEv2" refers to the IKE_SA_INIT and IKE_AUTH exchanges. "IPsec" refers to IP encapsulated in either AH or ESP. The intended status of this document is an Informational RFC that has been reviewed by the IETF. 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 values from both the initiator and the responder that the other party cannot predict in advance; because of this, the use of hash functions in IKEv1 and IKEv2 are not susceptible to any known collision-reduction attack. IKEv1 also uses has 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. 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 in identifying the trust roots. 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 same person holds both private keys. IKEv1 can be used together with 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 Hoffman Expires May 27, 2006 [Page 2] Internet-Draft IKE and IPsec Hash Use November 2005 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). HMACs are not susceptible to any known collision-reduction attack. 4. PKIX Certificates Some uses of IKEv1 and IKEv2 use PKIX certificates for authentication. As described in [HashAttacks], if a certificate authority (CA) issues certificates where the requesting party can predict the serial number and expiration date of the to-be-issued certificate, the requesting party can get a certificate that has a "shadow" certificate that has the same identity but different signing keys. This is not considered to be a useful attack in IKEv1 or IKEv2 because the same person holds both private keys. There is some speculation that this attack could be extended to allow a requesting party to get a certificate that has a "shadow" certificate that has a different identity (and possibly a different signing key). To date, there have been no examples of this in the cryptographic literature, and there have not even been any papers showing whether or not such an attack is even possible under the limitations of the current collision-reducing attacks. 5. 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 this with respect to IKEv1, IKEv2, and IPsec. 5.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 negotiation of hash functions because it is expected that the "preferred" hash function for different users will change over time. Hoffman Expires May 27, 2006 [Page 3] Internet-Draft IKE and IPsec Hash Use November 2005 IKEv1 and IKEv2 already allow for the negotiation of hash functions for both IKE and IPsec, and thus do not need any protocol change. 5.2. Suggested Changes for Implementors As described in earlier sections, IKE and IPsec 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 to hash functions, particularly the AES-XCBC-PRF-128 and AES-XCBC-MAC-96 algorithms. Implementers of IKE that allow certificate authentication should strongly consider allowing the use of certificates that are signed with the SHA-256 hash algorithm. 6. Security Considerations This entire document is about security, namely, 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. 7. Informative References [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [HashAttacks] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", draft-hoffman-hash-attacks-04 (work in progress), June 2005. [IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. Hoffman Expires May 27, 2006 [Page 4] Internet-Draft IKE and IPsec Hash Use November 2005 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), September 2004. [IKEv2Algs] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2", draft-ietf-ipsec-ikev2-algorithms-05 (work in progress), April 2004. [IPsecAlgs] Eastlake, D., "Cryptographic Algorithm Implementation Requirements For ESP And AH", draft-ietf-ipsec-esp-ah-algorithms-02 (work in progress), August 2004. [NAT-T] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. Appendix A. Acknowledgements Tero Kivinen helped with ideas in the first draft of this document. 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 Internet Society (2005). 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 AND THE INTERNET Hoffman Expires May 27, 2006 [Page 5] Internet-Draft IKE and IPsec Hash Use November 2005 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hoffman Expires May 27, 2006 [Page 6]