Internet DRAFT - draft-zhou-6man-mhash-cga

draft-zhou-6man-mhash-cga






6man                                                        S. Zhou, Ed.
Internet-Draft                                                  R. Zhang
Intended status: Standards Track                                  Z. Xie
Expires: March 17, 2013                                  ZTE Corporation
                                                      September 13, 2012


   Another Support for Multiple Hash Algorithms in Cryptographically
                       Generated Addresses (CGAs)
                      draft-zhou-6man-mhash-cga-02

Abstract

   This document provides a support for multiple hash algorithms 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 March 17, 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
   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.




Zhou, et al.             Expires March 17, 2013                 [Page 1]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Mhash-method Extension  . . . . . . . . . . . . . . . . . . . . 4
   3.  Hash Algorithm Identity Parameter . . . . . . . . . . . . . . . 4
   4.  CGA Generation Procedure  . . . . . . . . . . . . . . . . . . . 5
   5.  CGA Verification Procedure  . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8







































Zhou, et al.             Expires March 17, 2013                 [Page 2]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


1.  Introduction

   Cryptographically Generated Addresses (CGAs) defined in [RFC3972] is
   a method of binding a public key to an IPv6 address, with the aim of
   providing address ownership in many internet protocols.  In the
   generation and verification of a CGA address, a cryptographically
   secure hash function, SHA-1 in the case of [RFC3972], is used to hash
   a public key into part of the network IP address.

   As pointed out in Section 4 of [RFC4982], it is wise to enable
   multiple hash functions support in CGAs so that once the current hash
   function 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.

   To provide a sense of hash algorithms agility , a method of reusing
   the security parameter bits in the address is specified[RFC4982].
   Security parameter , sec, defined in [RFC3972], is a 3 bit value from
   0 to 7 used in the hash extension technique (Section 7.2 in [RFC3972]
   ), to compensate the truncated SHA-1 output length because of
   insufficient bits space in a CGA address.  According to the method
   specified in RFC4982, the security parameter is also used to
   represent hash algorithm identity:

      000 means sec=0 and SHA-1

      001 means sec=1 and SHA-1

      010 means sec=2 and SHA-1

   Then security parameter is limited to 0,1,2 .  They may be sufficient
   for now, but higher security parameter value may also be required
   with computers becoming faster, as pointed out in Section 7.2 , RFC
   3972.

   Even with limited security parameter value, the method in RFC 4982
   can only support three hash algorithms at most.  That is besides
   SHA-1, we have a second choice of an alternative hash algorithm
   number one with sec=0,1,2 and a third choice of another alternative
   hash algorithm number two with sec can only be two values from
   {0,1,2}.

   Taking the above two factors into consideration, at some time in the
   future we will be faced with a painful choice, high security
   parameter or a more secure hash algorithm?  And we may be also
   challenged with pain of high cost of upgrading because of the massive
   number of IPv6 nodes that may be using CGA addresses.



Zhou, et al.             Expires March 17, 2013                 [Page 3]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


   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, [RFC4982].

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


2.  Mhash-method Extension

   To accomodate RFC 4982, an extension field "Mhash-method" is defined.
   The format is illustrated in Figure 1.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Extension Type        |      Extension Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Mhash-method|
   +-+-+-+-+-+-+-+


   Extension Type: TBA. (16-bit unsigned integer).

   Extension Data Length: 1. (16-bit unsigned integer.  Length of the
   multiple-hash-method field of this option, in octets.)

   Mhash-method: 1 octet length field.  If Mhash-method equal 0, it
   means the method of denoting hash algorithm specified in RFC 4982 is
   adopted, if Mhash-method equal 1, it means the method specified in
   this document is adopted.


3.  Hash Algorithm Identity Parameter

   A hash algorithm identity parameter (hid) in CGA is defined to denote
   the hash algorithm adopted when calculating HASH1 and HASH2.  The
   hash algorithm identity parameter is a three-bit unsigned integer,
   and it is encoded in the 3rd-5th bits of the interface identifier.
   This can be written as follows:

   hid = (interface identifier & 0x1c00000000000000) >> 58



Zhou, et al.             Expires March 17, 2013                 [Page 4]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


        0 1 2 3 4 5 6 7 8 9 0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | sec | hid |0 0|   Leftmost 56 bits of HASH1 output            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.  CGA Generation Procedure

   Generate a CGA as defined in RFC 3972 except some modification to
   steps 2,3,5,6 and 9 as shown in the following:

   1.  Set the modifier to a random or pseudo-random 128-bit value.

   2.  Concatenate from left to right the modifier, 9 zero octets, the
       encoded public key, and any optional extension fields.  Execute
       the adopted hash algorithm ( denoted by value of hid) on the
       concatenation.  Take the 112( or 115 in case sec=7 ) leftmost
       bits of the hash value.  The result is Hash2.

   3.  Compare the 16*Sec+3 leftmost bits of Hash2 with zero.  If they
       are all zero, continue with step 4.  Otherwise, increment the
       modifier by one and go back to step 2.

   4.  Set the 8-bit collision count to zero.

   5.  Concatenate from left to right the final modifier value, the
       subnet prefix, the collision count, the encoded public key, and
       any optional extension fields.  Execute the adopted hash
       algorithm on the concatenation.  Take the 56 leftmost bits of the
       hash value.  The result is Hash1.

   6.  Form an interface identifier from Hash1 by writing the value of
       Sec into the three leftmost bits, writing the value of hid into
       the following three bits and by setting bits 6 and 7 (i.e., the
       "u" and "g" bits) to zero.

   7.  Concatenate the 64-bit subnet prefix and the 64-bit interface
       identifier to form a 128-bit IPv6 address with the subnet prefix
       to the left and interface identifier to the right, as in a
       standard IPv6 address .

   8.  Perform duplicate address detection if required.  If an address
       collision is detected, increment the collision count by one and
       go back to step 5.  However, after three collisions, stop and
       report the error.

   9.  Form the CGA Parameters data structure by concatenating from left
       to right the final modifier value, the subnet prefix, the final



Zhou, et al.             Expires March 17, 2013                 [Page 5]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


       collision count value, the encoded public key, Mhash-method value
       (equal 1 in this case) and any other optional extension fields.


5.  CGA Verification Procedure

   Verify a CGA as defined in RFC 3972 except some modification to steps
   3,4,6 and 7 as shown in the following:

   1.  Check that the collision count in the CGA Parameters data
       structure is 0, 1, or 2.  The CGA verification fails if the
       collision count is out of the valid range.

   2.  Check that the subnet prefix in the CGA Parameters data structure
       is equal to the subnet prefix (i.e., the leftmost 64 bits) of the
       address.  The CGA verification fails if the prefix values differ.

   3.  If the Mhash-method value in the Mhash-method extension filed is
       1, read the hash algorithm identity parameter hid from the 3rd-
       5th bits of the 64-bit interface identifier of the address,
       execute the hash algorithm denoted by hid on the CGA Parameters
       data structure.  Take the 56 leftmost bits of the hash value.
       The result is Hash1.  If the Mhash-method value in the Mhash-
       method extension filed is 0, do exactly as specified in RFC 3972
       and RFC4982.

   4.  Compare Hash1 with the interface identifier (i.e., the rightmost
       56 bits) of the address.  If the 56-bit values differ, the CGA
       verification fails.

   5.  Read the security parameter Sec from the three leftmost bits of
       the 64-bit interface identifier of the address.  (Sec is an
       unsigned 3-bit integer.)

   6.  Concatenate from left to right the modifier, 9 zero octets, the
       public key, and any extension fields that follow the public key
       in the CGA Parameters data structure.  Execute the hash algorithm
       denoted by hid on the concatenation.  Take the 112 (or 115 in
       case sec=7) leftmost bits of the SHA-1 hash value.  The result is
       Hash2.

   7.  Compare the 16*Sec+3 leftmost bits of Hash2 with zero.  If any
       one of them is not zero, the CGA verification fails.  Otherwise,
       the verification succeeds.







Zhou, et al.             Expires March 17, 2013                 [Page 6]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


6.  IANA Considerations

   This document defines one new CGA Extension Type [RFC4581] option,
   which must be assigned by IANA:

   Name: Mhash-method extension type;

   Value: TBA.

   Description: see Section 2.

   The values of Mhash-method are also defined:

   Name: Mhash-method extension value;

   Value: 0 meaning RFC 4982, 1 meaning this document;

   Description: see Section 2.

   This document also defines a new parameter (hid) in CGA, the value of
   which must be assigned by IANA.  It may be assigned as follows:

             Name        | Value
      -------------------+-------
            SHA-1        |   000
            SHA-244      |   001
            SHA-256      |   010
            SHA-384      |   011
            SHA-512      |   100
            TBD          |   101
            TBD          |   110
            TBD          |   111


7.  Security Considerations

   The security of applications using CGAs relies on the adopted public
   key schemes, which is out of the scope of this document, as well as
   the adopted hash algorithms.

   A high cryptographically secure hash algorithm is obviously required.
   But no hash algorithms are guaranteed to be secure for ever, it is
   wise to add algorithm agility into CGAs in case current hash
   algorithm be successfully attacked.

   This document suggests adding more flexible hash algorithm agility to
   CGAs.  The method in this document follows the idea of encoding the
   hash algorithm identifier in the interface identifier to avoid



Zhou, et al.             Expires March 17, 2013                 [Page 7]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


   downgrading attack, as analyzed in Section 4.1, RFC 4982.

   Actually CGAs only adopt truncated forms of a hash algorithm which is
   considered cryptographically secure in the sense of its regular form.
   As specified in RFC 3972, the effective bits relating to the security
   of CGAs are only the leftmost 59 bits (in the case of HASH1) , and
   the left most 16*sec bits (in the case of HASH2) of the whole 160
   bits SHA-1 output .  It is roughly estimated that the overall
   security of the hash algorithm is O( 2^(16*sec+59))(Section 7.2,
   RFC3972).

   In this document, 3 bits originally used for output of HASH1are taken
   off the interface identifier to denote hash algorithm identity, while
   3 more bits of output of HASH2 are checked, in a whole the whole
   security level is kept roughly the same, i.e.,O( 2^(16*sec+59)) .


8.  Normative References

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

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


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












Zhou, et al.             Expires March 17, 2013                 [Page 8]

Internet-Draft        draft-zhou-6man-mhash-cga-00        September 2012


   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 March 17, 2013                 [Page 9]