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]
