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

Versions: 00 01 02 03 04 05 06 RFC 4894

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]


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