[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4894

Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Expires: January 21, 2007                                  July 20, 2006

                Use of Hash Algorithms in IKE and IPsec

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 21, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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.

Hoffman                 Expires January 21, 2007                [Page 1]

Internet-Draft           IKE and IPsec Hash Use                July 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Hashes in IKEv1 and IKEv2  . . . . . . . . . . . . . . . . . .  3
   3.  Hashes in IPsec  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  PKIX Certificates in IKEv1 and IKEv2 . . . . . . . . . . . . .  4
   5.  Choosing Cryptographic Functions . . . . . . . . . . . . . . .  4
     5.1.  Multiple Cryptographic Functions . . . . . . . . . . . . .  5
     5.2.  Specifying Cryptographic Functions in the Protocol . . . .  5
     5.3.  Specifying Cryptographic Functions in Authentication . . .  6
   6.  Suggested Changes  . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Suggested Changes for the Protocols  . . . . . . . . . . .  7
     6.2.  Suggested Changes for Implementors . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  Informative References . . . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . .  9
   Appendix B.  PKIX issues . . . . . . . . . . . . . . . . . . . . .  9
   Appendix C.  Changes between versions  . . . . . . . . . . . . . . 10
     C.1.  Changes between -00 and -01  . . . . . . . . . . . . . . . 10
     C.2.  Changes between -01 and -02  . . . . . . . . . . . . . . . 11
     C.3.  Changes between -02 and -03  . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Hoffman                 Expires January 21, 2007                [Page 2]

Internet-Draft           IKE and IPsec Hash Use                July 2006

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

   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 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

   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 HMACs, and
   are thus not susceptible to any known collision-reduction attack.

   Both IKEv1 and IKEv2 have authentication modes that use digital
   signatures.  Digital signatures use hashes to make unique
   fingerprints of the message being signed.  Such signatures are not
   susceptible to collision attacks because they are not intended to
   have any non-repudiation or third-party-verification functionality.

Hoffman                 Expires January 21, 2007                [Page 3]

Internet-Draft           IKE and IPsec Hash Use                July 2006

   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
   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 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.

   There are (at least) three distinct subtopics related to choosing
   cryptographic functions in protocols:

Hoffman                 Expires January 21, 2007                [Page 4]

Internet-Draft           IKE and IPsec Hash Use                July 2006

   o  The ability to pick between multiple 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.  Multiple Cryptographic Functions

   Protocols that use cryptographic functions can either specify a
   single function, or can allow multiple 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 multiple hash functions in
   every place where hash functions are used.

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 in its list, possibly
   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

Hoffman                 Expires January 21, 2007                [Page 5]

Internet-Draft           IKE and IPsec Hash Use                July 2006

   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 being 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 SA

5.3.  Specifying Cryptographic Functions in Authentication

   Passing public key certificates 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 certificate
   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.

   The question of specifying cryptographic functions is only relevant
   if one party has multiple certificates with different cryptographic
   functions.  In this section, the terms "proposer" and "chooser" have
   a different meaning than in the previous section.  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,
   while other protocols only allow the proposer to send a single
   certificate.  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).

Hoffman                 Expires January 21, 2007                [Page 6]

Internet-Draft           IKE and IPsec Hash Use                July 2006

   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

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 this with respect to IKEv1, IKEv2, and

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 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 expected
   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.

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

   Note that some IKE and IPsec users will misunderstand the relevance

Hoffman                 Expires January 21, 2007                [Page 7]

Internet-Draft           IKE and IPsec Hash Use                July 2006

   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
   [AES-PRF] and AES-XCBC-MAC-96 [AES-MAC] algorithms.

   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.  Implementers of
   IKE that allow certificate authentication should strongly consider
   allowing the use of certificates that are signed with the SHA-256
   hash algorithm.  Similarly, those implementers should also strongly
   consider allowing the sending of multiple certificates for

7.  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.

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.

              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.

              Hoffman, P. and B. Schneier, "Attacks on Cryptographic
              Hashes in Internet Protocols",
              draft-hoffman-hash-attacks-04 (work in progress),

Hoffman                 Expires January 21, 2007                [Page 8]

Internet-Draft           IKE and IPsec Hash Use                July 2006

              June 2005.

   [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.

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

              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.

              Korver, B., "The Internet IP Security PKI Profile of
              IKEv1/ISAKMP, IKEv2, and PKIX",
              draft-ietf-pki4ipsec-ikecert-profile-08 (work in
              progress), February 2006.

Appendix A.  Acknowledgements

   Tero Kivinen helped with ideas in the first draft of this document.
   Many participants on the SAAG and IPsec mailing lists contributed
   ideas in later drafts.

Appendix B.  PKIX issues

   IMPORTANT NOTE: This section will be removed in a future version of
   this Internet Draft, certainly before it becomes an RFC.  It is left
   here to help whomever will be writing the document on PKIX hash use.

   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: the relying party views the
   attacker as the same entity because the identity is the same in both

Hoffman                 Expires January 21, 2007                [Page 9]

Internet-Draft           IKE and IPsec Hash Use                July 2006

   There is 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.  However, if such an attack is
   possible, it could have significant effects on protocols that rely on
   PKIX certificates.

   There are two possibilities of such a future attack.  If the second
   identity is valid but is a bunch of noise, the only implementations
   affected by the attack are ones whose policy is "accept anyone with a
   certificate signed by the CA"; this policy is rarely used in
   practice.  If the second identity is valid and is of another user who
   might normally be authenticated in the implementation, the attack is
   obviously, much more worrisome.

Appendix C.  Changes between versions

   (This section is to be removed by the RFC Editor.)

C.1.  Changes between -00 and -01

   Added that IKEv2 uses hash functions for its own integrity
   protection, based on a suggestion by Michael Richardson.

   Added description of use of digital signatures in IKEv1 and IKEv2,
   based on a suggestion from Hugo Krawczyk.

   Removed the description of specific PKIX attacks and remedies, and
   replaced it with pointers to the future PKIX work.  Added a section
   in the suggested changes to the protocols pointing out that some
   changes that come from the PKIX world will require no changes to IKE,
   but others might.

   Added the long section on "Choosing Cryptographic Functions" based on
   a suggestion from Steve Bellovin.

   Added references for AES-XCBC-PRF-128 and AES-XCBC-MAC-96, based on a
   suggestion from David McGrew.

   Strengthened the PKIX discussion that is now in an appendix, but will
   later be removed when the PKIX document is started.

Hoffman                 Expires January 21, 2007               [Page 10]

Internet-Draft           IKE and IPsec Hash Use                July 2006

C.2.  Changes between -01 and -02

   A bunch of editorial fixes from Alfred Hoenes.

   Updated the references to the new RFCs.

C.3.  Changes between -02 and -03

   None; just a freshening.

Hoffman                 Expires January 21, 2007               [Page 11]

Internet-Draft           IKE and IPsec Hash Use                July 2006

Author's Address

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

   Email: paul.hoffman@vpnc.org

Hoffman                 Expires January 21, 2007               [Page 12]

Internet-Draft           IKE and IPsec Hash Use                July 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


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

Hoffman                 Expires January 21, 2007               [Page 13]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/