6man                                                        S. Zhou, Ed.
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                             C.  Huitema
Expires: May 9, 2013                                           Microsoft
                                                                R. Zhang
                                                                  Z. Xie
                                                         ZTE Corporation
                                                        November 5, 2012


   Supporting Hash Algorithms Agility in Cryptographically Generated
                            Addresses (CGAs)
                    draft-zhou-6man-cga-hashagil-00

Abstract

   This document provides a discussion for solutions supporting hash
   algorithms agility in Cryptographically Generated Addresses (CGAs)
   defined in RFC 3972.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 9, 2013.

Copyright Notice

   Copyright (c) 2012 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



Zhou, et al.               Expires May 9, 2013                  [Page 1]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  CGAs  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.3.  Security of CGAs  . . . . . . . . . . . . . . . . . . . . . 3
     1.4.  Security Challenges in the Future . . . . . . . . . . . . . 4
   2.  Potential Solutions . . . . . . . . . . . . . . . . . . . . . . 6
     2.1.  Security Discussions  . . . . . . . . . . . . . . . . . . . 7
     2.2.  Compatibility Discussions . . . . . . . . . . . . . . . . . 8
   3.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9





























Zhou, et al.               Expires May 9, 2013                  [Page 2]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


1.  Introduction

   In this document, a support for multiple hash algorithms without
   limiting security parameter or downgrading the security level of CGAs
   is provided.  The proposed solution follows the idea of encoding the
   hash algorithm identity in the CGA addresses to prevent from
   downgrading attacks, the detailed description of downgrading attack
   can be found in Section 4.1, RFC 4982.

1.1.  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 [RFC2119].

1.2.  CGAs

   Cryptographically Generated Addresses (CGAs) [RFC3972] are a kind of
   stateless addresses, which means the addresses are used when a site
   is not particularly concerned with the exact addresses hosts use as
   long as they are unique and properly routable.  In contrast with
   other kinds of stateless addresses, CGAs are mainly used in
   situations where security is a concern, especially when address
   ownership and data integrity are required.

   CGAs have been used in Secure Neighbor Discovery (SEND)[RFC3971],
   Mobility in IPv6(MIPv6)[RFC4866], Site Multihoming by IPv6
   Intermediation (Shim6)[RFC5533], and securing DHCPv6
   [I-D.ietf-dhc-secure-dhcpv6].

   CGAs provide address ownership by hashing a public key and other
   information included in the accompanying CGA parameters to part of
   the IPv6 address (59 bits), and all messages sent by the host with a
   CGA go along with a signature calculated using the private key
   associated with the public key.  A receiver firstly recalculates the
   hash of the CGA parameters and compares the result with the CGA, if
   the they are equal, the CGA is valid, then the receiver continues to
   verify the signature.

1.3.  Security of CGAs

   The security of a CGA implementation relies on the public key
   cryptographic system adopted and the hash implementation.  For the
   public key cryptographic system, SEND [RFC3971] recommends using only
   RSA for compatibility between implementations, some other protocols
   may have their own choices by encoding algorithm identifier in
   SubjectPublicKeyInfo [RFC3280].  For the hash implementation, it is a
   bit more complex, because not only hash algorithms are concerned, but



Zhou, et al.               Expires May 9, 2013                  [Page 3]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


   also the output length of a hash algorithm is to be considered.

   For a perfect hash algorithm, the computation time an attacker takes
   to find a collision is 2^(L/2) , the time it takes t o find a second-
   preimage is 2^L, where L is the hash length[RFC4270].  For a
   practical hash algorithm, the effort an attacker needs could be less.
   So in addition to choosing a cryptographically strong hash algorithm,
   it is better to keep the hash length as long as it is originally
   designed.

   But there are some cases that cannot afford to hold the full hash
   length, CGA being one of them because the number of bits in an IPv6
   address is quite limited (128 bits in total including 64 bits for
   subnet network prefix) and a hash value has to be truncated from 160
   bits to 59 bits [RFC3972][RFC4982].  A technique called "hash
   extension" is proposed to compensate for the security loss induced by
   hash value truncation [hash-extension], by which both the attacker's
   and defender's efforts to calculate the same short hash value is
   increased by the same proportion, but the ratio of them is still
   bound by 2^L theoretically, where L is the truncated hash value
   length.  In the case of CGA defined in [RFC3972], L equals 59 and the
   proportion is 2^(16*SEC), where SEC is chosen from 0 to 7.
   Currently, SEC values between 0 and 2 are sufficient for most IPv6
   nodes.  As computers become faster, higher SEC values will slowly
   become useful.

1.4.  Security Challenges in the Future

   Crypto-analysis of the hash algorithms has made fast progress since
   2004, as shown in [RFC4270], which promotes [RFC4982] to enable
   multiple hash algorithms in CGAs so that once the current hash
   algorithm does not satisfy future requirements ,e.g., potential
   future applications of the CGAs may need a more cryptographically
   secure hash algorithm than SHA-1, the transition to an alternative
   hash function is as easy as possible.

   But where to encode the hash identity ?  There are two options
   considered in [RFC4982] : in a CGA address or in a CGA parameter.
   For the first option, there are only two places left to insert coding
   of hash algorithm identity, 3 bits of security parameter SEC and 59
   bits of truncated hash value.  To occupy SEC bits will make some SEC
   values unusable, to occupy bits assigned to hash value will further
   weaken the hash security since hash value length is of essentiality.
   For the second option, the advantage is that current CGA address
   allocation is not affected at all, especially truncated hash value is
   not to be weakened and SEC can choose from the whole range from 0 to
   7, but the problem is that this approach is vulnerable to bidding
   down attacks or downgrading attacks if no other security measures are



Zhou, et al.               Expires May 9, 2013                  [Page 4]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


   taken.

   [RFC4982] took the first option and occupied the same 3 bits SEC is
   using for hash algorithm identity, that is

             SEC Value   | Meaning
      -------------------+-------
             000         | sec=0 and SHA-1
             001         | sec=1 and SHA-1
             010         | sec=2 and SHA-1

   And other SEC values have not yet been defined.  As shown
   in[I-D.zhou-6man-mhash-cga], reusing SEC will limit both the security
   parameter values and available hash algorithms and ultimately make
   CGAs less flexible to be used for variant protocols.  For example, as
   mentioned in [RFC3972] it is suggested to start using a low sec value
   and to replace addresses with higher ones only when denial-of-service
   attacks based on brute-force search become a significant problem in
   some situations, and it is suggested to start with higher sec values
   directly in some situations where CGAs are used as a part of a strong
   authentication or secrecy mechanism.

   [I-D.zhou-6man-mhash-cga] took the first option and occupied 3 bits
   from the 59 bits assigned to hash value, and proposed to compensate
   the security loss by increasing hash extension security from
   2^(16*SEC) to 2^(16*SEC+3) .  The only concern to this approach is
   that the ratio of attacker's and defender's work to obtain the same
   CGA address is decreased from 2^59 to 2^56.

   Besides crypto-analysis of hash algorithms, the rapid progress in
   faster and cheaper processors, e.g., GPU, is another challenge to the
   security of CGAs in the near future.  A GPU is effectively a set of
   500 or 1000 microprocessors and much faster than a generic processor
   when doing highly parallel tasks, which means some calculation
   performed years ago about the safety of hashes may be wrong by 2 or 3
   orders of magnitude - in short, hashes should be 10 bits longer than
   expected a few years ago.  And technology is continue changing along
   the path.

   The security challenges show both higher SEC values and stronger hash
   algorithms are required.  For applications flexibility, a wide range
   of SEC values are preferred.  Because stronger hash algorithms are
   also restricted by the theoretical security bound which is a function
   of hash length, it is better to have more bits assigned to hash value
   in CGAs.  Thus the requirements for CGAs in the future may be:
   reasonable variant SEC values, as long as possible bits for hash
   value in a CGA , reasonable hash algorithm agility, and compatibility
   with current CGA implementations.



Zhou, et al.               Expires May 9, 2013                  [Page 5]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


2.  Potential Solutions

   There could be four types of potential solutions for enhancement of
   current CGAs, as shown in Figure 2.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        SEC in CGA         |     SEC in CGA Parameter          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | HID |[RFC 4982]               I |  II                               |
 | in  |[I-D.zhou-6man-mhash-cga]  | *SEC values =0... 255             |
 | CGA |                           | *hash length = 59~60 bits         |
 |     |                           | *HID max numbers =4~8             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | HID |                      III  | IV                                |
 | in  |*SEC values =0...7         |*SEC values =0...255               |
 | CGA |*hash length = 59 bits     |*hash length = 62 bits             |
 |Para-|*HID max numbers =255      |*HID max numbers =255              |
 |meter|                           |                                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type I solutions keep security parameter SEC in CGA address, I,e.,
   bits 0~2 in the interface identifier (the last 64 bits a in IPv6
   address), and let HID, encoding of hash algorithms, occupy bits in
   the interface identifier, either reusing SEC bits as in [RFC4982], or
   reclaim some bits from the 59 bits assigned to hash value as in
   [I-D.zhou-6man-mhash-cga], the summary of the SEC values, hash
   length, and HID max number can be found in the previous section.

   Type II solutions reclaim SEC bits and assign some or all of the 3
   bits to HID, and put SEC in CGA parameters.  Thus the length of hash
   value in a interface identifier can be 59 bits or 60 bits, the
   maximum number of supported hash algorithms can be 4 or 8.  SEC then
   could choose values from 0 to 255 providing more flexibility.

   Type III solutions keep SEC bits in CGA and put HID in CGA
   parameters.  Thus SEC values are unchanged, the length of hash value
   in a interface identifier is still 59 bits, the maximum number of
   supported hash algorithms could be 255 far more than what is actually
   needed.

   Type IV solutions reclaim SEC bits and put both SEC and HID in CGA
   parameters.  Thus the length of hash value in a interface identifier
   can be 62 bits, the maximum number of supported hash algorithms could
   be 255 far more than what is actually needed, SEC then could choose
   values from 0 to 255 providing more flexibility.





Zhou, et al.               Expires May 9, 2013                  [Page 6]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


2.1.  Security Discussions

   According to the security requirements for the future CGAs as
   mentioned in the previous section: reasonable variant SEC values,
   long bits for hash value in a CGA , reasonable hash algorithm
   agility, Type II, III, IV are all preferable to type I solutions.

   But as shown in Section 4, [RFC4982], all other solutions except type
   I are vulnerable to downgrading attacks if no other security measures
   are taken.  Specifically, addresses of type II and IV are at risks of
   attacks of using a less value of the SEC field, addresses of type III
   and IV are at risks of attacks of using a weaker hash algorithm.  It
   is arguable which kind of attacks are easier to implement.  If the
   goal of CGA is to counter against downgrading attacks using less SEC
   values, then type III solutions are suitable; if the goal of CGA is
   to counter against downgrading attacks using weaker hash algorithms,
   then type II solutions are preferable.  Type I solutions are immune
   to all the above mentioned downgrading attacks.

   To defend against downgrading attacks, receivers, who verify the CGA
   addresses, may adopt their own policy filter and refuse to trust CGA
   addresses if the hash algorithm is deemed to weak, or the SEC field
   too short.  This offers a protection against attempts to weaken the
   security of CGA by presenting insufficient values in parameter fields
   for addresses of type II, III and IV.  The senders who want to
   benefit from CGAs and obtain greater protection SHOULD adopt higher
   SEC values and stronger hash algorithms, but whether the effort of a
   sender is effective, is actually dependent on the protection level of
   policy at the receiver side .  If the receiver is so dumb as to
   accept any malformed address , there is nothing the sender can do.

   Type I solutions are attractive in secure against downgrading
   attacks, because SEC values and hash algorithms are hard coded in the
   addresses.  But type I solutions do not prevent careless senders
   themselves from choosing low SEC value or weaker hash algorithm.
   Security policy at the receiver side is still necessary.

   Using additional security measures, e.g., security policy, besides
   the security mechanism in CGAs themselves is reasonable and
   necessary.  CGAs are only utensils that could be used by any internet
   protocols, it is the responsibility of those protocols that should
   manage the risk of using CGAs improperly.  And those protocols have
   variant security requirements, it is impossible for the intrinsic
   security embedded in CGAs to fit for all their requirements.







Zhou, et al.               Expires May 9, 2013                  [Page 7]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


2.2.  Compatibility Discussions

   The solution of [RFC4982] in type I has a disadvantage that sometime
   in the future two different implementations may have different
   interpretation for the same SEC values, so 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.

   While other solutions do not have the problem of misinterpretation,
   they do need to consider the compatibility problem with current CGA
   implementations.  Various compatibility solutions could be taken.
   For example, currently undefined SEC=111 in [RFC4982] could be used
   to denote that actual security parameter and hash algorithm identity
   are included in CGA parameters.  For another example, version
   information could be added in CGA parameters or in CGA addresses,
   thus CGA without version information is looked as conforming to
   current implementation.


3.  Conclusions

   According to the above analysis, no solution type is absolutely
   better than others considering multiple factors, and any solution
   type could be compensated by additional security mechanism since CGA
   is only part of a bigger picture, e.g., security policy could be
   applied.  But considering later flexibility, cryptanalysis progress
   and computing capability advancement, current CGA solution (RFC4982)
   is debatable.


4.  IANA Considerations

   This document includes no request for IANA now, but may have request
   once the final solution is determined.


5.  Security Considerations

   See security discussions.


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Zhou, et al.               Expires May 9, 2013                  [Page 8]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 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

   [I-D.ietf-dhc-secure-dhcpv6]
              Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
              draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
              September 2012.

   [I-D.zhou-6man-mhash-cga]
              Zhou, S. and R. Zhang, "Another Support for Multiple Hash
              Algorithms in Cryptographically Generated Addresses
              (CGAs)", draft-zhou-6man-mhash-cga-02 (work in progress),
              September 2012.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
              Hashes in Internet Protocols", RFC 4270, November 2005.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [hash-extension]
              Microsoft Research, Cambridge, UK and Microsoft Research,
              Cambridge, UK, "Strengthening Short Hash Values".











Zhou, et al.               Expires May 9, 2013                  [Page 9]


Internet-Draft        draft-zhou-6man-mhash-cga-00         November 2012


Authors' Addresses

   Sujing Zhou (editor)
   ZTE Corporation
   No.68 Zijinghua Rd. Yuhuatai District
   Nanjing, Jiang Su  210012
   R.R.China

   Email: zhou.sujing@zte.com.cn


   Christian Huitema
   Microsoft


   Phone:
   Fax:
   Email: huitema@microsoft.com
   URI:


   Ruishan Zhang
   ZTE Corporation
   889 Bibo Rd, Zhangjiang Hi-Tech Park
   Shanghai  201203
   P.R.China

   Email: zhang.ruishan@zte.com.cn


   Zhenhua XIe
   ZTE Corporation
   No.68 Zijinghua Rd. Yuhuatai District
   Nanjing, Jiang Su  210012
   P.R.China

   Phone: +86-25-52871287
   Fax:   +86-25-52871000
   Email: xie.zhenhua@zte.com.cn












Zhou, et al.               Expires May 9, 2013                 [Page 10]