doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4894.txt b/doc/rfc/rfc4894.txt
new file mode 100644
index 0000000..0f2f622
--- /dev/null
+++ b/doc/rfc/rfc4894.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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
+   attacker can create two different Public Key Infrastructure using
+   X.509 (PKIX) certificates with different identities that have the
+   same signatures.
+
+   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 the trust anchors.  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
+   key generator holds both private keys.
+
+   IKEv1 can be used together with Network Access Translator (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).  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 packet authentication to want to spoof it.
+
+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.
+
+
+
+Hoffman                      Informational                      [Page 3]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+   There are (at least) three distinct subtopics related to choosing
+   cryptographic functions in protocols:
+
+   o  The ability to pick between different 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.  Different Cryptographic Functions
+
+   Protocols that use cryptographic functions can either specify a
+   single function, or can allow different 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 different hash functions in
+   every significant place where hash functions are used (that is, in
+   every place that has any susceptibility to a collision-reduction
+   attack).
+
+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 to its list, possibly
+
+
+
+
+
+Hoffman                      Informational                      [Page 4]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+   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
+   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 is 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 Security
+   Association (SA) establishment.
+
+5.3.  Specifying Cryptographic Functions in Authentication
+
+   Passing public key certificates and signatures 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
+   certification 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.  This can be non-PKIX certificates or other types of
+   cryptographic identity-binding structures that may be used in the
+   future.
+
+   The question of specifying cryptographic functions is only relevant
+   if one party has multiple certificates or signatures with different
+   cryptographic functions.  In this section, the terms "proposer" and
+   "chooser" have a different meaning than in the previous section.
+
+
+
+Hoffman                      Informational                      [Page 5]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+   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 or
+   signatures, while other protocols only allow the proposer to send a
+   single certificate or signature.  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).
+
+   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
+   identity.
+
+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 these areas with respect to IKEv1, IKEv2,
+   and IPsec.
+
+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 the 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 hoped 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.
+
+
+
+Hoffman                      Informational                      [Page 6]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+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
+   [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, particularly the AES-XCBC-PRF-128 [AES-PRF] and AES-
+   XCBC-MAC-96 [AES-MAC] algorithms, as well as forthcoming algorithms
+   based on the SHA-2 family [SHA2-HMAC].
+
+   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.  Implementors of
+   IKE that allow certificate authentication should strongly consider
+   allowing the use of certificates that are signed with the SHA-256,
+   SHA-384, and SHA-512 hash algorithms.  Similarly, those implementors
+   should also strongly consider allowing the sending of multiple
+   certificates for identification.
+
+7.  Security Considerations
+
+   This entire document is about 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                      Informational                      [Page 7]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+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.
+
+   [Deploying]          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.
+
+   [HashAttacks]        Hoffman, P. and B. Schneier, "Attacks on
+                        Cryptographic Hashes in Internet Protocols",
+                        RFC 4270, November 2005.
+
+   [HMAC-reduction]     Contini, S. and YL. Yin, "Forgery and Partial
+                        Key-Recovery Attacks on HMAC and NMAC Using Hash
+                        Collisions", Cryptology ePrint Report 2006/319,
+                        September 2006.
+
+   [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.
+
+   [IKEv2Algs]          Schiller, J., "Cryptographic Algorithms for use
+                        in the Internet Key Exchange Version 2",
+                        RFC 4307, December 2005.
+
+   [IPsecAlgs]          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.
+
+
+
+
+
+
+Hoffman                      Informational                      [Page 8]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+   [PKI4IPsec]          Korver, B., "The Internet IP Security PKI
+                        Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work
+                        in Progress, April 2007.
+
+   [SHA2-HMAC]          Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
+                        HMAC-SHA-384, and HMAC-SHA-512 With IPsec",
+                        RFC 4868, May 2007.
+
+   [Target-collisions]  Stevens, M., Lenstra, A., and B. de Weger,
+                        "Target Collisions for MD5 and Colliding X.509
+                        Certificates for Different Identities",
+                        Cryptology ePrint Report 2006/360, October 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                      Informational                      [Page 9]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+Appendix A.  Acknowledgments
+
+   Tero Kivinen helped with ideas in the first version of this document.
+   Many participants on the SAAG and IPsec mailing lists contributed
+   ideas in later versions.  In particular, suggestions were made by
+   Alfred Hoenes, Michael Richardson, Hugo Krawczyk, Steve Bellovin,
+   David McGrew, Russ Housley, Arjen Lenstra, and Pasi Eronen.
+
+Author's Address
+
+   Paul Hoffman
+   VPN Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+   US
+
+   EMail: paul.hoffman@vpnc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                      Informational                     [Page 10]
+
+RFC 4894                 IKE and IPsec Hash Use                 May 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST AND
+   THE INTERNET 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hoffman                      Informational                     [Page 11]
+