doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc4982.txt b/doc/rfc/rfc4982.txt
new file mode 100644
index 0000000..f1c3aa2
--- /dev/null
+++ b/doc/rfc/rfc4982.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                         M. Bagnulo
+Request for Comments: 4982                                          UC3M
+Updates: 3972                                                   J. Arkko
+Category: Standards Track                                       Ericsson
+                                                               July 2007
+
+
+                Support for Multiple Hash Algorithms in
+              Cryptographically Generated Addresses (CGAs)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document analyzes the implications of recent attacks on commonly
+   used hash functions on Cryptographically Generated Addresses (CGAs)
+   and updates the CGA specification to support multiple hash
+   algorithms.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   3.  Impact of Collision Attacks in CGAs . . . . . . . . . . . . . . 2
+   4.  Options for Multiple Hash Algorithm Support in CGAs . . . . . . 3
+     4.1.  Where to Encode the Hash Function?  . . . . . . . . . . . . 4
+   5.  CGA Generation Procedure  . . . . . . . . . . . . . . . . . . . 6
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 1]
+
+RFC 4982             Multiple Hash Support in CGAs             July 2007
+
+
+1.  Introduction
+
+   Recent attacks to currently used hash functions have motivated a
+   considerable amount of concern in the Internet community.  The
+   recommended approach [6] [10] to deal with this issue is first to
+   analyze the impact of these attacks on the different Internet
+   protocols that use hash functions and second to make sure that the
+   different Internet protocols that use hash functions are capable of
+   migrating to an alternative (more secure) hash function without a
+   major disruption in the Internet operation.
+
+   This document performs such analysis for the Cryptographically
+   Generated Addresses (CGAs) defined in [2].  The first conclusion of
+   the analysis is that the security of the protocols using CGAs is not
+   affected by the recently available attacks against hash functions.
+   The second conclusion of the analysis is that the hash function used
+   is hard coded in the CGA specification.  This document updates the
+   CGA specification [2] to enable the support of alternative hash
+   functions.  In order to do so, this document creates a new registry
+   managed by IANA to register the different hash algorithms used in
+   CGAs.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+3.  Impact of Collision Attacks in CGAs
+
+   Recent advances in cryptography have resulted in simplified attacks
+   against the collision-free property of certain commonly used hash
+   functions [6] [10], including SHA-1 that is the hash function used by
+   CGAs [2].  The result is that it is possible to obtain two messages,
+   M1 and M2, that have the same hash value with much less than 2^(L/2)
+   attempts.  We will next analyze the impact of such attacks in the
+   currently proposed usages of CGAs.
+
+   As we understand it, the attacks against the collision-free property
+   of a hash function mostly challenge the application of such hash
+   functions, for the provision of non-repudiation capabilities.  This
+   is because an attacker would be capable to create two different
+   messages that result in the same hash value and it can then present
+   any of the messages interchangeably (for example after one of them
+   has been signed by the other party involved in the transaction).
+   However, it must be noted that both messages must be generated by the
+   same party.
+
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 2]
+
+RFC 4982             Multiple Hash Support in CGAs             July 2007
+
+
+   As far as we understand, current usages of CGAs does not include the
+   provision of non-repudiation capabilities, so attacks against the
+   collision-free property of the hash function do not enable any useful
+   attack against CGA-based protocols.
+
+   Current usages of the CGAs are basically oriented to prove the
+   ownership of a CGA and then bind it to alternative addresses that can
+   be used to reach the original CGA.  This type of application of the
+   CGA include:
+
+   o  The application of CGAs to protect the shim6 protocol [7].  In
+      this case, CGAs are used as identifiers for the established
+      communications.  CGA features are used to prove that the owner of
+      the identifier is the one that is providing the alternative
+      addresses that can be used to reach the initial identifier.  This
+      is achieved by signing the list of alternative addresses available
+      in the multihomed host with the private key of the CGA.
+
+   o  The application of CGAs to secure the IPv6 mobility support
+      protocol [8] as proposed in [9].  In this case, the CGAs are used
+      as Home Addresses and they are used to prove that the owner of the
+      Home Address is the one creating the binding with the new Care-off
+      Address.  Similarly to the previous case, this is achieved by
+      signing the Binding Update message carrying the Care-off Address
+      with the private key of the CGA.
+
+   o  The application of CGA to Secure Neighbour Discovery [4].  In this
+      case, the CGA features are used to prove the address ownership, so
+      that it is possible to verify that the owner of the IP address is
+      the one that is providing the layer 2 address information.  This
+      is achieved by signing the layer 2 address information with the
+      private key of the CGA.
+
+   Essentially, all the current applications of CGAs rely on CGAs to
+   protect a communication between two peers from third party attacks
+   and not to provide protection from the peer itself.  Attacks against
+   the collision-free property of the hash functions suppose that one of
+   the parties is generating two messages with the same hash value in
+   order to launch an attack against its communicating peer.  Since CGAs
+   are not currently used to providing this type of protection, it is
+   then natural that no additional attacks are enabled by a weaker
+   collision resistance of the hash function.
+
+4.  Options for Multiple Hash Algorithm Support in CGAs
+
+   CGAs, as currently defined in [2], are intrinsically bound to the
+   SHA-1 hash algorithm and no other hash function is supported.
+
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 3]
+
+RFC 4982             Multiple Hash Support in CGAs             July 2007
+
+
+   Even though the attacks against the collision-free property of the
+   hash functions do not result in new vulnerabilities in the current
+   applications of CGAs, it seems wise to enable multiple hash function
+   support in CGAs.  This is mainly for two reasons: first, potential
+   future applications of the CGA technology may be susceptible to
+   attacks against the collision-free property of SHA-1.  Supporting
+   alternative hash functions would allow applications that have
+   stricter requirements on the collision-free property to use CGAs.
+   Second, one lesson learned from the recent attacks against hash
+   functions is that it is possible that one day we need to start using
+   alternative hash functions because of successful attacks against
+   other properties of the commonly used hash functions.  Therefore, it
+   seems wise to modify protocols in general and the CGAs in particular
+   to support this transition to alternative hash functions as easy as
+   possible.
+
+4.1.  Where to Encode the Hash Function?
+
+   The next question we need to answer is where to encode the hash
+   function that is being used.  There are several options that can be
+   considered:
+
+   One option would be to include the hash function used as an input to
+   the hash function.  This basically means to create an extension to
+   the CGA Parameter Data Structure, as defined in [3], that codifies
+   the hash function used.  The problem is that this approach is
+   vulnerable to bidding down attacks or downgrading attacks as defined
+   in [10].  This means that even if a strong hash function is used, an
+   attacker could find a CGA Parameter Data Structure that uses a weaker
+   function but results in an equal hash value.  This happens when the
+   original hash function H1 and CGA Parameters Data Structure
+   indicating H1 result in value X, and another hash function H2 and CGA
+   Parameters Data Structure indicating H2 also result in the same value
+   X.
+
+   In other words, the downgrading attack would work as follows: suppose
+   that Alice generates a CGA CGA_A using the strong hash function
+   HashStrong and using a CGA Parameter Data Structure CGA_PDS_A.  The
+   selected hash function HashStrong is encoded as an extension field in
+   the CGA_PDS_A.  Suppose that by using a brute force attack, an
+   attacker X finds an alternative CGA Parameter Data Structure
+   CGA_PDS_X whose hash value, by using a weaker hash function, is
+   CGA_A.  At this point, the attacker can pretend to be the owner of
+   CGA_A and the stronger hash function has not provided additional
+   protection.
+
+   The conclusion from the previous analysis is that the hash function
+   used in the CGA generation must be encoded in the address itself.
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 4]
+
+RFC 4982             Multiple Hash Support in CGAs             July 2007
+
+
+   Since we want to support several hash functions, we will likely need
+   at least 2 or 3 bits for this.
+
+   One option would be to use more bits from the hash bits of the
+   interface identifier.  However, the problem with this approach is
+   that the resulting CGA is weaker because less hash information is
+   encoded in the address.  In addition, since those bits are currently
+   used as hash bits, it is impossible to make this approach backward
+   compatible with existent implementations.
+
+   Another option would be to use the "u" and the "g" bits to encode
+   this information, but this is probably not such a good idea since
+   those bits have been honoured so far in all interface identifier
+   generation mechanisms, which allow them to be used for the original
+   purpose (for instance we can still create a global registry for
+   unique interface identifiers).  Finally, another option is to encode
+   the hash value used in the Sec bits.  The Sec bits are used to
+   artificially introduce additional difficulty in the CGA generation
+   process in order to provide additional protection against brute force
+   attacks.  The Sec bits have been designed in a way that the lifetime
+   of CGAs are extended, when it is feasible to attack 59-bits long hash
+   values.  However, this is not the case today, so in general CGA will
+   have a Sec value of 000.  The proposal is to encode in the Sec bits,
+   not only information about brute force attack protection but also to
+   encode the hash function used to generate the hash.  So for instance,
+   the Sec value 000 would mean that the hash function used is SHA-1 and
+   the 0 bits of hash2 (as defined in RFC 3972) must be 0.  Sec value of
+   001 could be that the hash function used is SHA-1 and the 16 bits of
+   hash2 (as defined in RFC 3972) must be zero.  However, the other
+   values of Sec could mean that an alternative hash function needs to
+   be used and that a certain amount of bits of hash2 must be zero.  The
+   proposal is not to define any concrete hash function to be used for
+   other Sec values, since it is not yet clear that we need to do so nor
+   is it clear which hash function should be selected.
+
+   Note that since there are only 8 Sec values, it may be necessary to
+   reuse Sec values when we run out of unused Sec values.  The scenario
+   where such an approach makes sense is where there are some Sec values
+   that are no longer being used because the resulting security has
+   become weak.  In this case, where the usage of the Sec value has long
+   been abandoned, it would be possible to reassign the Sec values.
+   However, this must be a last resource option, since it may affect
+   interoperability.  This is because two implementations using
+   different meanings of a given Sec value would not be able to
+   interoperate properly (i.e., if an old implementation receives a CGA
+   generated with the new meaning of the Sec value, it will fail and the
+   same for a new implementation receiving a CGA generated with the old
+   meaning of the Sec value).  In case the approach of reassigning a Sec
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 5]
+
+RFC 4982             Multiple Hash Support in CGAs             July 2007
+
+
+   value is followed, a long time is required between the deprecation of
+   the old value and the reassignment in order to prevent
+   misinterpretation of the value by old implementations.
+
+   An erroneous interpretation of a reused Sec value, both on the CGA
+   owner's side and the CGA verifier's side, would have the following
+   result, CGA verification would fail in the worst case and both nodes
+   would have to revert to unprotected IPv6 addresses.  This can happen
+   only with obsolete CGA parameter sets, which would be considered
+   insecure anyway.  In any case, an implementation must not
+   simultaneously support two different meanings of a Sec value.
+
+5.  CGA Generation Procedure
+
+   The SEC registry defined in the IANA considerations section of this
+   document contains entries for the different Sec values.  Each of
+   these entries points to an RFC that defines the CGA generation
+   procedure that MUST be used when generating CGAs with the associated
+   Sec value.
+
+   It should be noted that the CGA generation procedure may be changed
+   by the new procedure not only in terms of the hash function used but
+   also in other aspects, e.g., longer Modifier values may be required
+   if the number of 0s required in hash2 exceed the currently defined
+   bound of 112 bits.  The new procedure (which potentially involves a
+   longer Modifier value) would be described in the RFC pointed to by
+   the corresponding Sec registry entry.
+
+   In addition, the RFC that defines the CGA generation procedure for a
+   Sec value MUST explicitly define the minimum key length acceptable
+   for CGAs with that Sec value.  This is to provide a coherent
+   protection both in the hash and the public key techniques.
+
+6.  IANA Considerations
+
+   This document defines a new registry entitled "CGA SEC" for the Sec
+   field defined in RFC 3972 [2] that has been created and is maintained
+   by IANA.  The values in this name space are 3-bit unsigned integers.
+
+   Initial values for the CGA Extension Type field are given below;
+   future assignments are to be made through Standards Action [5].
+   Assignments consist of a name, the value, and the RFC number where
+   the CGA generation procedure is defined.
+
+
+
+
+
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 6]
+
+RFC 4982             Multiple Hash Support in CGAs             July 2007
+
+
+   The following initial values are assigned in this document:
+
+          Name        | Value |  RFCs
+   -------------------+-------+------------
+   SHA-1_0hash2bits   |   000 | 3972, 4982
+   SHA-1_16hash2bits  |   001 | 3972, 4982
+   SHA-1_32hash2bits  |   010 | 3972, 4982
+
+7.  Security Considerations
+
+   This document is about security issues and, in particular, about
+   protection against potential attacks against hash functions.
+
+8.  Acknowledgements
+
+   Russ Housley, James Kempf, Christian Vogt, Pekka Nikander, and Henrik
+   Levkowetz reviewed and provided comments about this document.
+
+   Marcelo Bagnulo worked on this document while visiting Ericsson
+   Research Laboratory Nomadiclab.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Aura, T., "Cryptographically Generated Addresses (CGA)",
+         RFC 3972, March 2005.
+
+   [3]   Bagnulo, M. and J. Arkko, "Cryptographically Generated
+         Addresses (CGA) Extension Field Format", RFC 4581,
+         October 2006.
+
+   [4]   Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+         Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+9.2.  Informative References
+
+   [5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434,
+         October 1998.
+
+   [6]   Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
+         in Internet Protocols", RFC 4270, November 2005.
+
+
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 7]
+
+RFC 4982             Multiple Hash Support in CGAs             July 2007
+
+
+   [7]   Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
+         Work in Progress, July 2005.
+
+   [8]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+         IPv6", RFC 3775, June 2004.
+
+   [9]   Arkko, J., "Applying Cryptographically Generated Addresses and
+         Credit-Based Authorization to Mobile IPv6", Work in Progress,
+         June 2006.
+
+   [10]  Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm",
+         NDSS '06, February 2006.
+
+Authors' Addresses
+
+   Marcelo Bagnulo
+   Universidad Carlos III de Madrid
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   SPAIN
+
+   Phone: 34 91 6249500
+   EMail: marcelo@it.uc3m.es
+   URI:   http://www.it.uc3m.es
+
+
+   Jari Arkko
+   Ericsson
+   Jorvas  02420
+   Finland
+
+   EMail: jari.arkko@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 8]
+
+RFC 4982             Multiple Hash Support in CGAs             July 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.
+
+
+
+
+
+
+
+Bagnulo & Arkko             Standards Track                     [Page 9]
+