idnits 2.17.1 draft-arkko-mipv6-select-hash-00.txt: -(14): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(16): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding ** The Abstract section seems to be numbered -(48): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(58): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(59): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(75): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(84): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(261): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(277): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(285): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(296): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(313): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(315): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(337): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(342): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(361): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 16 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 113 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 84: '...ute Optimization MUST derive the inter...' RFC 2119 keyword, line 133: '...is specification MUST NOT be used when...' RFC 2119 keyword, line 145: '... node MUST send D and P1, P2, ... ...' RFC 2119 keyword, line 150: '... The mobile node MUST NOT request a se...' RFC 2119 keyword, line 156: '...rrespondent node MUST verify that the ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 31 has weird spacing: '...t>, and expir...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 June 2002) is 7976 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) -- Looks like a reference, but probably isn't: 'TBD' on line 198 == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-16 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2373 (ref. '7') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2462 (ref. '8') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (ref. '9') (Obsoleted by RFC 4941) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-23 -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '13') Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jari Arkko 3 INTERNET-DRAFT Pekka Nikander 4 Category: Standards Track Ericsson 5 Gabriel Montenegro 6 SUN Microsystems 7 24 June 2002 9 Selection of MIPv6 Security Level Using a Hashed Address 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. Internet-Drafts are working docu� 15 ments of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute work� 17 ing documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or made obsolete by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts may be found at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories may be found at 28 http://www.ietf.org/shadow.html. 30 The distribution of this memo is unlimited. It is filed as , and expires December 24, 2002. 32 Please send comments to the author and/or to the MOBILE IP Working 33 Group mailing list. 35 2. Abstract 37 MIPv6 is being defined with a security solution called Return 38 Routability (RR) that does not need any authentication infrastructure. 39 Given that the solution is "infrastructureless" in this manner, it 40 isn't very easy to control the solution once it is widely deployed. In 41 particular, it isn't clear how the solution could be changed to a new 42 solution, should that ever become necessary. Peers should be able to 43 agree about the use the new solution in a secure manner, without Man- 44 in-the-Middle attackers from being able to mount a Bidding Down attack 45 and downgrade the security back to the original solution. This draft 46 specifies a simple but secure scheme which allows nodes to choose what 47 security solution they use. One currently known drawback of this 48 scheme is that it is based on a technology that has IPR considera� 49 tions. 51 3. Introduction 53 Mobile IPv6 (MIPv6) [1] Route Optimization (RO) functionality needs a 54 security solution that can be used between previously unknown peers, 55 without trusted third parties, and on a global scale. MIPv6 is now 56 being defined with a security solution for this purpose, called Return 57 Routability (RR) [1]. This solution does not require any trusted third 58 parties, i.e. it does not require a security infrastructure. There� 59 fore, it may be described as being "infrastructureless" (IFL). Alter� 60 native solutions, such as Cryptographically Generated Addresses (CGA) 61 have also been suggested [4, 5] but are not being standardized as the 62 mandatory solution at the moment. 64 Given that the solutions, such as RR, are infrastructureless, it isn't 65 very easy to control the solutions once they have been widely 66 deployed. In particular, it isn't clear how the solution could be 67 changed to a new solution, should that ever become necessary. Peers 68 should be able to agree about the use the new solution in a secure 69 manner, without Man-in-the-Middle attackers from being able to mount a 70 Bidding Down attack and downgrade the security back to the original 71 solution. 73 This draft specifies a simple scheme which allows nodes to choose what 74 security solution they use. It is secure only if all nodes that 75 engage in redirection operations (including but not necessarily lim� 76 ited to MIPv6 route optimization) adhere to it. Accordingly,for it to 77 be secure against "bidding down" attacks, this method needs to be 78 mandatory for all nodes implementing the base MIPv6 specification. 79 The scheme does not use any additional infrastructure. 81 4. Hash Based Addresses Scheme 83 In the Hash Based Addresses (HBA) scheme, all mobile nodes that wish 84 to employ MIPv6 Route Optimization MUST derive the interface identi� 85 fier part of their addresses in the following way: 87 1. Select the security parameter Sec = 0, 1 , 2, 3. It can be 88 used to tune the amount of work needed to create hashed 89 addresses. The rationale for Sec is discussed more in depth 90 in [12] 92 2. Calculate ID' 94 ID' = HASH("HBA" | Sec | R | D | P1 | P2 | ... | Pn) 96 Where 98 - ID' is the base of the 64 bit interface identifier of the home 99 address of the mobile node. The first 64 bits from the result 100 of the HASH function are taken to get ID'. 102 - HASH is the one-way hash algorithm SHA1 [13]. 104 - "HBA" is the three octet long string consisting of the ASCII 105 characters 'H', 'B', and 'A'. 107 - Sec is the security parameter represented as one octet. 109 - R is the 64 bit routing prefix part of the home address of 110 the mobile node. This is necessary in order to prevent 111 a global table attack described in section 3.2 of reference 112 [6]. 114 - D is a random 16 byte value. 116 - P1, P2, ... Pn are parameters selected by the mobile node. 118 3. Select 64+20 x Sec rightmost bits of the hash output and compare 119 the 20 x Sec leftmost bits to zero. If not zero, proceed to 120 generate a new random value of D and go back to Step 2. 122 4. To get the final interface identifier ID, set the group 123 and the universal bits [7] to 1 and the two rightmost bits 124 to Sec. 126 5. Concatenate the 64-bit Routing Prefix and the 64-bit 127 ID to obtain a 128-bit IPv6 address. 129 6. Perform Duplicate Address Detection. If collision is detected, 130 proceed to generate a new Random value and return to Step 2. 131 After three collisions, stop and report error. 133 This specification MUST NOT be used when interface identifiers are 134 shorter than 64 bits, to avoid attackers from using exhaustive search 135 to find out suitable addresses and their parameters. 137 The parameters P1, P2, ... Pn are used to indicate properties that the 138 mobile node wishes to attach to its address. This specification only 139 deals with the MIPv6 Route Optimization security method as such a 140 property, and does not discuss other uses the same scheme might have. 141 The exact format of parameters is defined in Section 5. The behaviour 142 rules for mobile nodes are as follows: 144 - When sending a Binding Update to a correspondent node, the mobile 145 node MUST send D and P1, P2, ... Pn along in that same message, as 146 well as to inform the correspondent node of the home address that uses 147 the prefix R. The exact format used to send D and P1, P2, ... Pn is 148 described in section 6. 150 - The mobile node MUST NOT request a security method that has not been 151 listed in one of the parameters. 153 The behaviour rules for correspondent nodes are as follows: 155 - When receiving a Binding Update from a mobile node with home address 156 A, the correspondent node MUST verify that the interface identifier 157 part of A equals to ID calculated as described in Steps 1 to 4 above. 158 The parameters Sec and R can be extracted from the home address of the 159 mobile node. The parameters D and P1, P2, ... Pn MUST be present in 160 the same Binding Update. 162 - The correspondent node MUST also verify that the requested security 163 method has been listed in one of the parameters. If it has not been 164 listed, the node MUST silently discard the Binding Update. 166 5. Hash Input Parameter Format 168 Each parameter is of the following format: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Parameter Type | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Parameter Value | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 The Parameter Type field is an IANA-allocated identifier that 179 describes what kind of parameter is being given. The currently legal 180 values are: 182 1 MIPv6 Route Optimization security method 184 If the Parameter Type field contains a value that is not recognized by 185 the receiver, it MUST ignore the parameter. Receivers MUST go through 186 every parameter to find out the parameters that it recognizes. If 187 there are no recognized parameters, the receiver MUST behave as if the 188 address was a regular address formed without hashing. 190 The interpretation of the Parameter Value field depends on the value 191 of Parameter Type field. If the value is MIPv6 Route Optimization 192 security method (1), the value is a bit mask where each bit that is 193 one denotes a specifically allowed security method. The currently 194 defined bit values are as follows: 196 Bit 0 Return Routability [1] 197 Bit 1 AAA [TBD] 198 Bit 2 Cryptographically Generated Addresses with public key [TBD] 200 6. Binding Update Option Format 202 The MIPv6 specification [1] defines the Mobility Header which can be 203 used to carry the Binding Update Message. This message may have 204 optional Options. In order to inform the correspondent node about the 205 values D and P1, P2, ... Pn used in the creation of the hashed 206 address, D and P1, P2, ... Pn are put inside a new Option, the Hashed 207 Address Option, defined below: 209 Hashed Address Option (alignment requirement: 8n+6) 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | 5 | 16+8n | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 217 | D | 218 | | 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | P1 | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | P2 | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | .... | 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Pn | 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 The Prefix Length field contains the number of bits used form the 235 routing prefix when calculating the hash. 237 The Reserved fields are reserved for future use. They MUST be set to 238 zero by the sender and ignored by receivers. 240 The D field contains the 16 byte random value, D discussed in Section 241 4. 243 The P1, P2, ... Pn fields contain the 8 byte parameter value in the 244 format discussed in Section 5. 246 7. Operational Considerations 248 Sites that wish to employ a particular MIPv6 RO security mechanism 249 should ensure that all nodes within the site generate their addresses 250 using the scheme described in this specification, and list only the 251 desired method in the parameters. 253 Nodes that do not use this specification will automatically be blocked 254 from the use of RO. All stationary nodes should continue to be 255 assigned addresses either in automatic, random, or configured manner 256 [8, 9, 10]. 258 Some sites rely on DHCPv6 [10] to assign addresses to all nodes, 259 including mobile nodes. With the HBA scheme, address assignment is not 260 as straightforward since the nodes need the relevant parameters and 261 random numbers as well in order to be able to use them for Route Opti� 262 mization. Some sites may not be operationally prepared to automate and 263 administer such a transfer of information. 265 8. Security Considerations 267 This specification is an alternative approach to the so called "bit 268 method" described in [11]. Most of the security aspects of these two 269 methods are equivalent and have been already adequately described in 270 [11]. This method is also largely vulnerable to the same problems as 271 the bit method is, if there are any. 273 The main benefits include ability to close some vulnerabilities 274 related to the malicious use of MIPv6 RO against stationary hosts, 275 preventing a Man-in-the-Middle from modifying security method requests 276 and expectations of mobile nodes therefore givinge mobile nodes an 277 ability to securely control what level of security is used when creat� 278 ing bindings for them at correspondent nodes. The attackers can still 279 invent new addresses and redirect them, but this does not seem to be 280 relevant for the mobile node. 282 The main differences between this and the bit method are: 284 - Given that no special bit is allocated, this method does not open 285 allow attackers to know whether nodes are mobile or not; the parame� 286 ters become known only if disclosed by the mobile node itself. This 287 reduces some of the privacy and DoS concerns related to disclosing 288 this information directly from the bit. 290 - Verifying the hash costs one hash operation, which is more expensive 291 that checking an individual bit. 293 - More information than a single bit can be protected. In particular, 294 this method is not vulnerable to the so called "bidding aside" problem 295 that the bit method is. That is, this method can choose between an 296 unlimited number of security methods, whereas the bit method is lim� 297 ited to choosing only between a "weak" and "strong" levels. 299 - Operational considerations may limit the use of this method in some 300 cases. 302 The hashing scheme described here is vulnerable to exhaustive search 303 of the set of possible random numbers and parameters. Reference [5] 304 discusses the feasibility of mounting such an attack. 306 9. Acknowledgements 308 CGA methods have been described earlier in various sources [2,3,4,5], 309 and HBA is simple variant of CGA. The difficulty of selecting between 310 two different levels of security has been discussed by the MIPv6 311 Design Team (Erik Nordmark and the authors of this draft) in several 312 context, as well as in [6]. Mike Roe and Tuomas Aura came up with the 313 idea of using a hash without a public key as a solution to this prob� 314 lem i.e. the basic idea described in this draft. The authors of this 315 draft have merely acted as editors. The idea of using the Sec parame� 316 ter is due to Tuomas Aura and has also been documented in [12]. 318 10. Intellectual Property Rights Notices 320 IPR claims have been made over CGA methods in general, and the claims 321 may apply also to kind of CGAs described in this draft. Ericsson's IPR 322 may apply here, and the Ericsson policy on IPR issues can be checked 323 from the Ericsson General IPR statement for IETF, 324 http://www.ietf.org/ietf/IPR/ERICSSON-General. 326 11. References 328 [1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- 329 mobileip-ipv6-16.txt. Work In Progress, IETF, March 2002. 331 [2] P. Nikander. A Scaleable Architecture for IPv6 Address Ownership. 332 Internet draft, March 2001. 334 [3] Greg O'Shea and Michael Roe. Child-proof authentication for MIPv6 335 (CAM). Computer Communications Review, April 2001. 337 [4] Michael Roe, Tuomas Aura, Greg O'Shea, and Jari Arkko. Authenti� 338 cation of Mobile IPv6 binding updates and acknowledgments. Internet 339 Draft draft-roe-mobileip-updateauth-02.txt, IETF Mobile IP Working 340 Group, February 2002. Work in progress. 342 [5] G. Montenegro and C. Castelluccia. Statistically Unique and Cryp� 343 tographically Verifiable (SUCV) Identifiers and Addresses. NDSS 2002, 344 February 2002. 346 [6] Tuomas Aura and Jari Arkko. MIPv6 BU Attacks and Defenses. 347 Internet Draft draft-aura-mipv6-bu-attacks-01.txt (Work In Progress), 348 IETF, February 2002. 350 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", 351 RFC 2373, July 1998. 353 [8] Thomson, S. and T. Narten, "IPv6 Address Autoconfiguration", RFC 354 2462, December 1998. 356 [9] T. Narten, R. Draves. Privacy Extensions for Stateless Address 357 Autoconfiguration in IPv6. RFC 3041, January 2001. 359 [10] J. Bound, M. Carney, C. Perkins, Ted Lemon, Bernie Volz, R. 360 Droms(ed.). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 361 Internet Draft draft-ietf-dhc-dhcpv6-23.txt (Work In Progress), Febru� 362 ary 2002. 364 [11] G. Montenegro, P. Nikander. "Protecting Against Bidding Down 365 Attacks". Internet Draft draft-montenegro-mipv6sec-bit-method-00.txt 366 (Work In Progress), April 2002. 368 [12] J. Arkko, T. Aura, J. Kempf, V.-M. Mantyla, P. Nikander, M. Roe 369 "Securing IPv6 Neighbor Discovery". Submitted for publication, 2002. 371 [13] D. Eastlake, P. Jones "US Secure Hash Algorithm 1 (SHA1)", RFC 372 3174, September 2001. 374 12. Author's Address 376 Jari Arkko 377 Oy LM Ericsson Ab 378 02420 Jorvas 379 Finland 381 EMail: Jari.Arkko@nomadiclab.com 383 Pekka Nikander 384 Oy LM Ericsson Ab 385 02420 Jorvas 386 Finland 388 EMail: Pekka.Nikander@nomadiclab.com 390 Gabriel Montenegro 391 Sun Labs, Europe 392 29, chemin du Vieux Chene 393 38240 Meylan 394 France 396 EMail: gab@sun.com