datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec
RFC 4894

Document type: RFC - Informational (May 2007)
Was draft-hoffman-ike-ipsec-hash-use (individual in sec area)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4894 (Informational)
Responsible AD: Russ Housley
Send notices to: paul.hoffman@vpnc.org

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

[include full document text]