idnits 2.17.1 draft-zhou-6man-mhash-cga-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 13, 2012) is 4236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4581' is mentioned on line 249, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man S. Zhou, Ed. 3 Internet-Draft R. Zhang 4 Intended status: Standards Track Z. Xie 5 Expires: March 17, 2013 ZTE Corporation 6 September 13, 2012 8 Another Support for Multiple Hash Algorithms in Cryptographically 9 Generated Addresses (CGAs) 10 draft-zhou-6man-mhash-cga-02 12 Abstract 14 This document provides a support for multiple hash algorithms in 15 Cryptographically Generated Addresses (CGAs) defined in RFC 3972. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 17, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Mhash-method Extension . . . . . . . . . . . . . . . . . . . . 4 54 3. Hash Algorithm Identity Parameter . . . . . . . . . . . . . . . 4 55 4. CGA Generation Procedure . . . . . . . . . . . . . . . . . . . 5 56 5. CGA Verification Procedure . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 Cryptographically Generated Addresses (CGAs) defined in [RFC3972] is 65 a method of binding a public key to an IPv6 address, with the aim of 66 providing address ownership in many internet protocols. In the 67 generation and verification of a CGA address, a cryptographically 68 secure hash function, SHA-1 in the case of [RFC3972], is used to hash 69 a public key into part of the network IP address. 71 As pointed out in Section 4 of [RFC4982], it is wise to enable 72 multiple hash functions support in CGAs so that once the current hash 73 function does not satisfy future requirements ,e.g., potential future 74 applications of the CGAs may need a more cryptographically secure 75 hash algorithm than SHA-1, the transition to an alternative hash 76 function is as easy as possible. 78 To provide a sense of hash algorithms agility , a method of reusing 79 the security parameter bits in the address is specified[RFC4982]. 80 Security parameter , sec, defined in [RFC3972], is a 3 bit value from 81 0 to 7 used in the hash extension technique (Section 7.2 in [RFC3972] 82 ), to compensate the truncated SHA-1 output length because of 83 insufficient bits space in a CGA address. According to the method 84 specified in RFC4982, the security parameter is also used to 85 represent hash algorithm identity: 87 000 means sec=0 and SHA-1 89 001 means sec=1 and SHA-1 91 010 means sec=2 and SHA-1 93 Then security parameter is limited to 0,1,2 . They may be sufficient 94 for now, but higher security parameter value may also be required 95 with computers becoming faster, as pointed out in Section 7.2 , RFC 96 3972. 98 Even with limited security parameter value, the method in RFC 4982 99 can only support three hash algorithms at most. That is besides 100 SHA-1, we have a second choice of an alternative hash algorithm 101 number one with sec=0,1,2 and a third choice of another alternative 102 hash algorithm number two with sec can only be two values from 103 {0,1,2}. 105 Taking the above two factors into consideration, at some time in the 106 future we will be faced with a painful choice, high security 107 parameter or a more secure hash algorithm? And we may be also 108 challenged with pain of high cost of upgrading because of the massive 109 number of IPv6 nodes that may be using CGA addresses. 111 In this document, a support for multiple hash algorithms without 112 limiting security parameter or downgrading the security level of CGAs 113 is provided. The proposed solution follows the idea of encoding the 114 hash algorithm identity in the CGA addresses to prevent from 115 downgrading attacks, the detailed description of downgrading attack 116 can be found in Section 4.1, [RFC4982]. 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Mhash-method Extension 126 To accomodate RFC 4982, an extension field "Mhash-method" is defined. 127 The format is illustrated in Figure 1. 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Extension Type | Extension Length | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Mhash-method| 135 +-+-+-+-+-+-+-+ 137 Extension Type: TBA. (16-bit unsigned integer). 139 Extension Data Length: 1. (16-bit unsigned integer. Length of the 140 multiple-hash-method field of this option, in octets.) 142 Mhash-method: 1 octet length field. If Mhash-method equal 0, it 143 means the method of denoting hash algorithm specified in RFC 4982 is 144 adopted, if Mhash-method equal 1, it means the method specified in 145 this document is adopted. 147 3. Hash Algorithm Identity Parameter 149 A hash algorithm identity parameter (hid) in CGA is defined to denote 150 the hash algorithm adopted when calculating HASH1 and HASH2. The 151 hash algorithm identity parameter is a three-bit unsigned integer, 152 and it is encoded in the 3rd-5th bits of the interface identifier. 153 This can be written as follows: 155 hid = (interface identifier & 0x1c00000000000000) >> 58 156 0 1 2 3 4 5 6 7 8 9 0 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | sec | hid |0 0| Leftmost 56 bits of HASH1 output | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 4. CGA Generation Procedure 163 Generate a CGA as defined in RFC 3972 except some modification to 164 steps 2,3,5,6 and 9 as shown in the following: 166 1. Set the modifier to a random or pseudo-random 128-bit value. 168 2. Concatenate from left to right the modifier, 9 zero octets, the 169 encoded public key, and any optional extension fields. Execute 170 the adopted hash algorithm ( denoted by value of hid) on the 171 concatenation. Take the 112( or 115 in case sec=7 ) leftmost 172 bits of the hash value. The result is Hash2. 174 3. Compare the 16*Sec+3 leftmost bits of Hash2 with zero. If they 175 are all zero, continue with step 4. Otherwise, increment the 176 modifier by one and go back to step 2. 178 4. Set the 8-bit collision count to zero. 180 5. Concatenate from left to right the final modifier value, the 181 subnet prefix, the collision count, the encoded public key, and 182 any optional extension fields. Execute the adopted hash 183 algorithm on the concatenation. Take the 56 leftmost bits of the 184 hash value. The result is Hash1. 186 6. Form an interface identifier from Hash1 by writing the value of 187 Sec into the three leftmost bits, writing the value of hid into 188 the following three bits and by setting bits 6 and 7 (i.e., the 189 "u" and "g" bits) to zero. 191 7. Concatenate the 64-bit subnet prefix and the 64-bit interface 192 identifier to form a 128-bit IPv6 address with the subnet prefix 193 to the left and interface identifier to the right, as in a 194 standard IPv6 address . 196 8. Perform duplicate address detection if required. If an address 197 collision is detected, increment the collision count by one and 198 go back to step 5. However, after three collisions, stop and 199 report the error. 201 9. Form the CGA Parameters data structure by concatenating from left 202 to right the final modifier value, the subnet prefix, the final 203 collision count value, the encoded public key, Mhash-method value 204 (equal 1 in this case) and any other optional extension fields. 206 5. CGA Verification Procedure 208 Verify a CGA as defined in RFC 3972 except some modification to steps 209 3,4,6 and 7 as shown in the following: 211 1. Check that the collision count in the CGA Parameters data 212 structure is 0, 1, or 2. The CGA verification fails if the 213 collision count is out of the valid range. 215 2. Check that the subnet prefix in the CGA Parameters data structure 216 is equal to the subnet prefix (i.e., the leftmost 64 bits) of the 217 address. The CGA verification fails if the prefix values differ. 219 3. If the Mhash-method value in the Mhash-method extension filed is 220 1, read the hash algorithm identity parameter hid from the 3rd- 221 5th bits of the 64-bit interface identifier of the address, 222 execute the hash algorithm denoted by hid on the CGA Parameters 223 data structure. Take the 56 leftmost bits of the hash value. 224 The result is Hash1. If the Mhash-method value in the Mhash- 225 method extension filed is 0, do exactly as specified in RFC 3972 226 and RFC4982. 228 4. Compare Hash1 with the interface identifier (i.e., the rightmost 229 56 bits) of the address. If the 56-bit values differ, the CGA 230 verification fails. 232 5. Read the security parameter Sec from the three leftmost bits of 233 the 64-bit interface identifier of the address. (Sec is an 234 unsigned 3-bit integer.) 236 6. Concatenate from left to right the modifier, 9 zero octets, the 237 public key, and any extension fields that follow the public key 238 in the CGA Parameters data structure. Execute the hash algorithm 239 denoted by hid on the concatenation. Take the 112 (or 115 in 240 case sec=7) leftmost bits of the SHA-1 hash value. The result is 241 Hash2. 243 7. Compare the 16*Sec+3 leftmost bits of Hash2 with zero. If any 244 one of them is not zero, the CGA verification fails. Otherwise, 245 the verification succeeds. 247 6. IANA Considerations 249 This document defines one new CGA Extension Type [RFC4581] option, 250 which must be assigned by IANA: 252 Name: Mhash-method extension type; 254 Value: TBA. 256 Description: see Section 2. 258 The values of Mhash-method are also defined: 260 Name: Mhash-method extension value; 262 Value: 0 meaning RFC 4982, 1 meaning this document; 264 Description: see Section 2. 266 This document also defines a new parameter (hid) in CGA, the value of 267 which must be assigned by IANA. It may be assigned as follows: 269 Name | Value 270 -------------------+------- 271 SHA-1 | 000 272 SHA-244 | 001 273 SHA-256 | 010 274 SHA-384 | 011 275 SHA-512 | 100 276 TBD | 101 277 TBD | 110 278 TBD | 111 280 7. Security Considerations 282 The security of applications using CGAs relies on the adopted public 283 key schemes, which is out of the scope of this document, as well as 284 the adopted hash algorithms. 286 A high cryptographically secure hash algorithm is obviously required. 287 But no hash algorithms are guaranteed to be secure for ever, it is 288 wise to add algorithm agility into CGAs in case current hash 289 algorithm be successfully attacked. 291 This document suggests adding more flexible hash algorithm agility to 292 CGAs. The method in this document follows the idea of encoding the 293 hash algorithm identifier in the interface identifier to avoid 294 downgrading attack, as analyzed in Section 4.1, RFC 4982. 296 Actually CGAs only adopt truncated forms of a hash algorithm which is 297 considered cryptographically secure in the sense of its regular form. 298 As specified in RFC 3972, the effective bits relating to the security 299 of CGAs are only the leftmost 59 bits (in the case of HASH1) , and 300 the left most 16*sec bits (in the case of HASH2) of the whole 160 301 bits SHA-1 output . It is roughly estimated that the overall 302 security of the hash algorithm is O( 2^(16*sec+59))(Section 7.2, 303 RFC3972). 305 In this document, 3 bits originally used for output of HASH1are taken 306 off the interface identifier to denote hash algorithm identity, while 307 3 more bits of output of HASH2 are checked, in a whole the whole 308 security level is kept roughly the same, i.e.,O( 2^(16*sec+59)) . 310 8. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 316 RFC 3972, March 2005. 318 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 319 Algorithms in Cryptographically Generated Addresses 320 (CGAs)", RFC 4982, July 2007. 322 Authors' Addresses 324 Sujing Zhou (editor) 325 ZTE Corporation 326 No.68 Zijinghua Rd. Yuhuatai District 327 Nanjing, Jiang Su 210012 328 R.R.China 330 Email: zhou.sujing@zte.com.cn 331 Ruishan Zhang 332 ZTE Corporation 333 889 Bibo Rd, Zhangjiang Hi-Tech Park 334 Shanghai 201203 335 P.R.China 337 Email: zhang.ruishan@zte.com.cn 339 Zhenhua XIe 340 ZTE Corporation 341 No.68 Zijinghua Rd. Yuhuatai District 342 Nanjing, Jiang Su 210012 343 P.R.China 345 Phone: +86-25-52871287 346 Fax: +86-25-52871000 347 Email: xie.zhenhua@zte.com.cn