doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc6273.txt b/doc/rfc/rfc6273.txt
new file mode 100644
index 0000000..599410c
--- /dev/null
+++ b/doc/rfc/rfc6273.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Kukec
+Request for Comments: 6273                          University of Zagreb
+Category: Informational                                      S. Krishnan
+ISSN: 2070-1721                                                 Ericsson
+                                                                S. Jiang
+                                            Huawei Technologies Co., Ltd
+                                                               June 2011
+
+
+       The Secure Neighbor Discovery (SEND) Hash Threat Analysis
+
+Abstract
+
+   This document analyzes the use of hashes in Secure Neighbor Discovery
+   (SEND), the possible threats to these hashes and the impact of recent
+   attacks on hash functions used by SEND.  The SEND specification
+   currently uses the SHA-1 hash algorithm and PKIX certificates
+   and does not provide support for hash algorithm agility.  This
+   document provides an analysis of possible threats to the hash
+   algorithms used in SEND.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any
+   errata, and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6273.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kukec, et al.                 Informational                     [Page 1]
+
+RFC 6273                SEND Hash Threat Analysis              June 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Impact of Collision Attacks on SEND . . . . . . . . . . . . . . 3
+     2.1.  Attacks against CGAs Used in SEND . . . . . . . . . . . . . 3
+     2.2.  Attacks against PKIX Certificates in Authorization
+           Delegation Discovery Process  . . . . . . . . . . . . . . . 3
+     2.3.  Attacks against the Digital Signature in the SEND RSA
+           Signature Option  . . . . . . . . . . . . . . . . . . . . . 4
+     2.4.  Attacks against the Key Hash Field of the SEND RSA
+           Signature Option  . . . . . . . . . . . . . . . . . . . . . 4
+   3.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+
+1.  Introduction
+
+   SEND [RFC3971] uses the SHA-1 hash algorithm [SHA1] to generate the
+   contents of the Key Hash field and the Digital Signature field of the
+   RSA Signature option.  It also indirectly uses a hash algorithm
+   (SHA-1, MD5, etc.) in the PKIX certificates [RFC5280] used for router
+   authorization in the Authorization Delegation Discovery (ADD)
+   process.  Recently there have been demonstrated attacks against the
+   collision free property of such hash functions [SHA1-COLL] and
+   attacks on the PKIX X.509 certificates that use the MD5 hash
+   algorithm [X509-COLL].  The document analyzes the impacts of these
+   attacks on SEND and it recommends mechanisms to make SEND resistant
+   to such attacks.
+
+
+
+
+
+Kukec, et al.                 Informational                     [Page 2]
+
+RFC 6273                SEND Hash Threat Analysis              June 2011
+
+
+2.  Impact of Collision Attacks on SEND
+
+   [RFC4270] summarizes a study that assesses the threat of the
+   aforementioned attacks on the use of cryptographic hashes in Internet
+   protocols.  This document analyzes the hash usage in SEND following
+   the approach recommended by [RFC4270] and [NEW-HASHES].
+
+   The following sections discuss the various aspects of hash usage in
+   SEND and determine whether they are affected by the attacks on the
+   underlying hash functions.
+
+2.1.  Attacks against CGAs Used in SEND
+
+   Cryptographically Generated Addresses (CGAs) are defined in [RFC3972]
+   and are used to securely associate a cryptographic public key with an
+   IPv6 address in the SEND protocol.  Impacts of collision attacks on
+   current uses of CGAs are analyzed in [RFC4982].  The basic idea
+   behind collision attacks, as described in Section 4 of [RFC4270], is
+   on the non-repudiation feature of hash algorithms.  However, CGAs do
+   not provide non-repudiation features.  Therefore, as [RFC4982] points
+   out CGA-based protocols, including SEND, are not affected by
+   collision attacks on hash functions.  If pre-image attacks were to
+   become feasible, an attacker can find new CGA Parameters that can
+   generate the same CGA as the victim.  This class of attacks could be
+   potentially dangerous since the security of SEND messages relies on
+   the strength of the CGA.
+
+2.2.  Attacks against PKIX Certificates in Authorization Delegation
+      Discovery Process
+
+   To protect Router Discovery, SEND requires that routers be authorized
+   to act as routers.  Routers are authorized by provisioning them with
+   certificates from a trust anchor, and the hosts are configured with
+   the trust anchor(s) used to authorize routers.  Researchers
+   demonstrated attacks against PKIX certificates with MD5 signatures in
+   2005 [NEW-HASHES], in 2007 [X509-COLL] [STEV2007] [SLdeW2007], and in
+   2009 [SSALMOdeW2009] [SLdeW2009].  An attacker can take advantage of
+   these vulnerabilities to obtain a certificate with a different
+   identity and use the certificate to impersonate a router.  For this
+   attack to succeed, the attacker needs to predict the content of all
+   fields (some of them are human-readable) appearing before the public
+   key, including the serial number and validity periods.  Even though a
+   relying party cannot verify the content of these fields, the CA can
+   identify the forged certificate, if necessary.
+
+
+
+
+
+
+
+Kukec, et al.                 Informational                     [Page 3]
+
+RFC 6273                SEND Hash Threat Analysis              June 2011
+
+
+2.3.  Attacks against the Digital Signature in the SEND RSA Signature
+      Option
+
+   The digital signature in the RSA Signature option is produced by
+   signing, with the sender's private key, the SHA-1 hash over certain
+   fields in the Neighbor Discovery message as described in Section 5.2
+   of [RFC3971].  It is possible for an attacker to come up with two
+   different Neighbor Discovery messages m and m' that result in the
+   same value in the Digital Signature field.  Since the structure of
+   the Neighbor Discovery messages is well defined, it is not practical
+   to use this vulnerability in real world attacks.
+
+2.4.  Attacks against the Key Hash Field of the SEND RSA Signature
+      Option
+
+   The SEND RSA signature option described in Section 5.2 of [RFC3971]
+   defines a Key Hash field.  This field contains a SHA-1 hash of the
+   public key that was used to generate the CGA.  To use a collision
+   attack on this field, the attacker needs to come up with another
+   public key (k') that produces the same hash as the real key (k).  But
+   the real key (k) is already authorized through a parallel mechanism
+   (either CGAs or router certificates).  Hence, collision attacks are
+   not possible on the Key Hash field.  Pre-image attacks on the Key
+   Hash field are not useful for the same reason (any other key that
+   hashes into the same Key Hash value will be detected due to a
+   mismatch with the CGA or the router certificate).
+
+3.  Conclusion
+
+   Current attacks on hash functions do not constitute any practical
+   threat to the digital signatures used in SEND (both in the RSA
+   signature option and in the X.509 certificates).  Attacks on CGAs, as
+   described in [RFC4982], will compromise the security of SEND and they
+   need to be addressed by encoding the hash algorithm information into
+   the CGA as specified in [RFC4982].
+
+4.  Security Considerations
+
+   This document analyzes the impact that the attacks against hash
+   functions have on SEND.  It concludes that the only practical attack
+   on SEND stems from a successful attack on an underlying CGA.  It does
+   not add any new vulnerabilities to SEND.
+
+
+
+
+
+
+
+
+
+Kukec, et al.                 Informational                     [Page 4]
+
+RFC 6273                SEND Hash Threat Analysis              June 2011
+
+
+5.  Acknowledgements
+
+   The authors would like to thank Lars Eggert, Pete McCann, Julien
+   Laganier, Jari Arkko, Paul Hoffman, Pasi Eronen, Adrian Farrel, Dan
+   Romascanu, Tim Polk, Richard Woundy, Marcelo Bagnulo, and Barry Leiba
+   for reviewing earlier versions of this document and providing
+   comments to make it better.
+
+6.  References
+
+6.1.  Normative References
+
+   [NEW-HASHES] Bellovin, S. and E. Rescorla, "Deploying a New Hash
+                Algorithm", November 2005.
+
+   [RFC4270]    Hoffman, P. and B. Schneier, "Attacks on Cryptographic
+                Hashes in Internet Protocols", RFC 4270, November 2005.
+
+   [RFC4982]    Bagnulo, M. and J. Arkko, "Support for Multiple Hash
+                Algorithms in Cryptographically Generated Addresses
+                (CGAs)", RFC 4982, July 2007.
+
+6.2.  Informative References
+
+   [RFC3971]    Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+                "SEcure Neighbor Discovery (SEND)", RFC 3971, March
+                2005.
+
+   [RFC3972]    Aura, T., "Cryptographically Generated Addresses (CGA)",
+                RFC 3972, March 2005.
+
+   [RFC5280]    Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+                Housley, R., and W. Polk, "Internet X.509 Public Key
+                Infrastructure Certificate and Certificate Revocation
+                List (CRL) Profile", RFC 5280, May 2008.
+
+   [SHA1]       NIST, FIPS PUB 180-1, "Secure Hash Standard", April
+                1995.
+
+   [SHA1-COLL]  Wang, X., Yin, L., and H. Yu, "Finding Collisions in the
+                Full SHA-1. CRYPTO 2005: 17-36", 2005.
+
+   [SLdeW2007]  Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix
+                Collisions for MD5 and Colliding X.509 Certificates for
+                Different Identities".  EuroCrypt 2007.
+
+
+
+
+
+
+Kukec, et al.                 Informational                     [Page 5]
+
+RFC 6273                SEND Hash Threat Analysis              June 2011
+
+
+   [SLdeW2009]  Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix
+                Collisions for MD5 and Applications, Journal of
+                Cryptology", 2009, <http://deweger.xs4all.nl/
+                papers/%5B42%5DStLedW-MD5-JCryp%5B2009%5D.pdf>.
+
+   [SSALMOdeW2009]
+                Stevens, M., Sotirov, A., Appelbaum, J., Lenstra, A.,
+                Molnar, D., Osvik, D., and B. de Weger., "Short chosen-
+                prefix collisions for MD5 and the creation of a rogue CA
+                certificate, Crypto 2009", 2009.
+
+   [STEV2007]   Stevens, M., "On Collisions for MD5",
+                <http://www.win.tue.nl/hashclash/
+                On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf>.
+
+   [X509-COLL]  Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix
+                Collisions for MD5 and Colliding X.509 Certificates for
+                Different Identities. EUROCRYPT 2007: 1-22", 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kukec, et al.                 Informational                     [Page 6]
+
+RFC 6273                SEND Hash Threat Analysis              June 2011
+
+
+Authors' Addresses
+
+   Ana Kukec
+   University of Zagreb
+   Unska 3
+   Zagreb
+   Croatia
+
+   EMail: ana.kukec@fer.hr
+
+
+   Suresh Krishnan
+   Ericsson
+   8400 Decarie Blvd.
+   Town of Mount Royal, QC
+   Canada
+
+   EMail: suresh.krishnan@ericsson.com
+
+
+   Sheng Jiang
+   Huawei Technologies Co., Ltd
+   Huawei Building, No.3 Xinxi Rd.,
+   Shang-Di Information Industry Base, Hai-Dian District, Beijing
+   P.R. China
+
+   EMail: jiangsheng@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kukec, et al.                 Informational                     [Page 7]
+