Network Working Group Jari Arkko INTERNET-DRAFT Pekka Nikander Category: Standards Track Ericsson Gabriel Montenegro SUN Microsystems 24 June 2002 Selection of MIPv6 Security Level Using a Hashed Address 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working docu¡ ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work¡ ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete 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. The list of current Internet-Drafts may be found at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories may be found at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires December 24, 2002. Please send comments to the author and/or to the MOBILE IP Working Group mailing list. 2. Abstract MIPv6 is being defined with a security solution called Return Routability (RR) that does not need any authentication infrastructure. Given that the solution is "infrastructureless" in this manner, it isn't very easy to control the solution once it is widely deployed. In particular, it isn't clear how the solution could be changed to a new solution, should that ever become necessary. Peers should be able to agree about the use the new solution in a secure manner, without Man- in-the-Middle attackers from being able to mount a Bidding Down attack and downgrade the security back to the original solution. This draft specifies a simple but secure scheme which allows nodes to choose what security solution they use. One currently known drawback of this scheme is that it is based on a technology that has IPR considera¡ tions. J. Arkko et al [Page 1] INTERNET-DRAFT Selection using a hash 24 June 2002 3. Introduction Mobile IPv6 (MIPv6) [1] Route Optimization (RO) functionality needs a security solution that can be used between previously unknown peers, without trusted third parties, and on a global scale. MIPv6 is now being defined with a security solution for this purpose, called Return Routability (RR) [1]. This solution does not require any trusted third parties, i.e. it does not require a security infrastructure. There¡ fore, it may be described as being "infrastructureless" (IFL). Alter¡ native solutions, such as Cryptographically Generated Addresses (CGA) have also been suggested [4, 5] but are not being standardized as the mandatory solution at the moment. Given that the solutions, such as RR, are infrastructureless, it isn't very easy to control the solutions once they have been widely deployed. In particular, it isn't clear how the solution could be changed to a new solution, should that ever become necessary. Peers should be able to agree about the use the new solution in a secure manner, without Man-in-the-Middle attackers from being able to mount a Bidding Down attack and downgrade the security back to the original solution. This draft specifies a simple scheme which allows nodes to choose what security solution they use. It is secure only if all nodes that engage in redirection operations (including but not necessarily lim¡ ited to MIPv6 route optimization) adhere to it. Accordingly,for it to be secure against "bidding down" attacks, this method needs to be mandatory for all nodes implementing the base MIPv6 specification. The scheme does not use any additional infrastructure. 4. Hash Based Addresses Scheme In the Hash Based Addresses (HBA) scheme, all mobile nodes that wish to employ MIPv6 Route Optimization MUST derive the interface identi¡ fier part of their addresses in the following way: 1. Select the security parameter Sec = 0, 1 , 2, 3. It can be used to tune the amount of work needed to create hashed addresses. The rationale for Sec is discussed more in depth in [12] 2. Calculate ID' ID' = HASH("HBA" | Sec | R | D | P1 | P2 | ... | Pn) Where - ID' is the base of the 64 bit interface identifier of the home address of the mobile node. The first 64 bits from the result of the HASH function are taken to get ID'. - HASH is the one-way hash algorithm SHA1 [13]. - "HBA" is the three octet long string consisting of the ASCII J. Arkko et al [Page 2] INTERNET-DRAFT Selection using a hash 24 June 2002 characters 'H', 'B', and 'A'. - Sec is the security parameter represented as one octet. - R is the 64 bit routing prefix part of the home address of the mobile node. This is necessary in order to prevent a global table attack described in section 3.2 of reference [6]. - D is a random 16 byte value. - P1, P2, ... Pn are parameters selected by the mobile node. 3. Select 64+20 x Sec rightmost bits of the hash output and compare the 20 x Sec leftmost bits to zero. If not zero, proceed to generate a new random value of D and go back to Step 2. 4. To get the final interface identifier ID, set the group and the universal bits [7] to 1 and the two rightmost bits to Sec. 5. Concatenate the 64-bit Routing Prefix and the 64-bit ID to obtain a 128-bit IPv6 address. 6. Perform Duplicate Address Detection. If collision is detected, proceed to generate a new Random value and return to Step 2. After three collisions, stop and report error. This specification MUST NOT be used when interface identifiers are shorter than 64 bits, to avoid attackers from using exhaustive search to find out suitable addresses and their parameters. The parameters P1, P2, ... Pn are used to indicate properties that the mobile node wishes to attach to its address. This specification only deals with the MIPv6 Route Optimization security method as such a property, and does not discuss other uses the same scheme might have. The exact format of parameters is defined in Section 5. The behaviour rules for mobile nodes are as follows: - When sending a Binding Update to a correspondent node, the mobile node MUST send D and P1, P2, ... Pn along in that same message, as well as to inform the correspondent node of the home address that uses the prefix R. The exact format used to send D and P1, P2, ... Pn is described in section 6. - The mobile node MUST NOT request a security method that has not been listed in one of the parameters. The behaviour rules for correspondent nodes are as follows: - When receiving a Binding Update from a mobile node with home address A, the correspondent node MUST verify that the interface identifier part of A equals to ID calculated as described in Steps 1 to 4 above. The parameters Sec and R can be extracted from the home address of the J. Arkko et al [Page 3] INTERNET-DRAFT Selection using a hash 24 June 2002 mobile node. The parameters D and P1, P2, ... Pn MUST be present in the same Binding Update. - The correspondent node MUST also verify that the requested security method has been listed in one of the parameters. If it has not been listed, the node MUST silently discard the Binding Update. 5. Hash Input Parameter Format Each parameter is of the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Parameter Type field is an IANA-allocated identifier that describes what kind of parameter is being given. The currently legal values are: 1 MIPv6 Route Optimization security method If the Parameter Type field contains a value that is not recognized by the receiver, it MUST ignore the parameter. Receivers MUST go through every parameter to find out the parameters that it recognizes. If there are no recognized parameters, the receiver MUST behave as if the address was a regular address formed without hashing. The interpretation of the Parameter Value field depends on the value of Parameter Type field. If the value is MIPv6 Route Optimization security method (1), the value is a bit mask where each bit that is one denotes a specifically allowed security method. The currently defined bit values are as follows: Bit 0 Return Routability [1] Bit 1 AAA [TBD] Bit 2 Cryptographically Generated Addresses with public key [TBD] 6. Binding Update Option Format The MIPv6 specification [1] defines the Mobility Header which can be used to carry the Binding Update Message. This message may have optional Options. In order to inform the correspondent node about the values D and P1, P2, ... Pn used in the creation of the hashed address, D and P1, P2, ... Pn are put inside a new Option, the Hashed Address Option, defined below: Hashed Address Option (alignment requirement: 8n+6) 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 J. Arkko et al [Page 4] INTERNET-DRAFT Selection using a hash 24 June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 16+8n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | D | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pn | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Prefix Length field contains the number of bits used form the routing prefix when calculating the hash. The Reserved fields are reserved for future use. They MUST be set to zero by the sender and ignored by receivers. The D field contains the 16 byte random value, D discussed in Section 4. The P1, P2, ... Pn fields contain the 8 byte parameter value in the format discussed in Section 5. 7. Operational Considerations Sites that wish to employ a particular MIPv6 RO security mechanism should ensure that all nodes within the site generate their addresses using the scheme described in this specification, and list only the desired method in the parameters. Nodes that do not use this specification will automatically be blocked from the use of RO. All stationary nodes should continue to be assigned addresses either in automatic, random, or configured manner [8, 9, 10]. Some sites rely on DHCPv6 [10] to assign addresses to all nodes, including mobile nodes. With the HBA scheme, address assignment is not as straightforward since the nodes need the relevant parameters and random numbers as well in order to be able to use them for Route Opti¡ mization. Some sites may not be operationally prepared to automate and administer such a transfer of information. J. Arkko et al [Page 5] INTERNET-DRAFT Selection using a hash 24 June 2002 8. Security Considerations This specification is an alternative approach to the so called "bit method" described in [11]. Most of the security aspects of these two methods are equivalent and have been already adequately described in [11]. This method is also largely vulnerable to the same problems as the bit method is, if there are any. The main benefits include ability to close some vulnerabilities related to the malicious use of MIPv6 RO against stationary hosts, preventing a Man-in-the-Middle from modifying security method requests and expectations of mobile nodes therefore givinge mobile nodes an ability to securely control what level of security is used when creat¡ ing bindings for them at correspondent nodes. The attackers can still invent new addresses and redirect them, but this does not seem to be relevant for the mobile node. The main differences between this and the bit method are: - Given that no special bit is allocated, this method does not open allow attackers to know whether nodes are mobile or not; the parame¡ ters become known only if disclosed by the mobile node itself. This reduces some of the privacy and DoS concerns related to disclosing this information directly from the bit. - Verifying the hash costs one hash operation, which is more expensive that checking an individual bit. - More information than a single bit can be protected. In particular, this method is not vulnerable to the so called "bidding aside" problem that the bit method is. That is, this method can choose between an unlimited number of security methods, whereas the bit method is lim¡ ited to choosing only between a "weak" and "strong" levels. - Operational considerations may limit the use of this method in some cases. The hashing scheme described here is vulnerable to exhaustive search of the set of possible random numbers and parameters. Reference [5] discusses the feasibility of mounting such an attack. 9. Acknowledgements CGA methods have been described earlier in various sources [2,3,4,5], and HBA is simple variant of CGA. The difficulty of selecting between two different levels of security has been discussed by the MIPv6 Design Team (Erik Nordmark and the authors of this draft) in several context, as well as in [6]. Mike Roe and Tuomas Aura came up with the idea of using a hash without a public key as a solution to this prob¡ lem i.e. the basic idea described in this draft. The authors of this draft have merely acted as editors. The idea of using the Sec parame¡ ter is due to Tuomas Aura and has also been documented in [12]. J. Arkko et al [Page 6] INTERNET-DRAFT Selection using a hash 24 June 2002 10. Intellectual Property Rights Notices IPR claims have been made over CGA methods in general, and the claims may apply also to kind of CGAs described in this draft. Ericsson's IPR may apply here, and the Ericsson policy on IPR issues can be checked from the Ericsson General IPR statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General. 11. References [1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-16.txt. Work In Progress, IETF, March 2002. [2] P. Nikander. A Scaleable Architecture for IPv6 Address Ownership. Internet draft, March 2001. [3] Greg O'Shea and Michael Roe. Child-proof authentication for MIPv6 (CAM). Computer Communications Review, April 2001. [4] Michael Roe, Tuomas Aura, Greg O'Shea, and Jari Arkko. Authenti¡ cation of Mobile IPv6 binding updates and acknowledgments. Internet Draft draft-roe-mobileip-updateauth-02.txt, IETF Mobile IP Working Group, February 2002. Work in progress. [5] G. Montenegro and C. Castelluccia. Statistically Unique and Cryp¡ tographically Verifiable (SUCV) Identifiers and Addresses. NDSS 2002, February 2002. [6] Tuomas Aura and Jari Arkko. MIPv6 BU Attacks and Defenses. Internet Draft draft-aura-mipv6-bu-attacks-01.txt (Work In Progress), IETF, February 2002. [7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [8] Thomson, S. and T. Narten, "IPv6 Address Autoconfiguration", RFC 2462, December 1998. [9] T. Narten, R. Draves. Privacy Extensions for Stateless Address Autoconfiguration in IPv6. RFC 3041, January 2001. [10] J. Bound, M. Carney, C. Perkins, Ted Lemon, Bernie Volz, R. Droms(ed.). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Internet Draft draft-ietf-dhc-dhcpv6-23.txt (Work In Progress), Febru¡ ary 2002. [11] G. Montenegro, P. Nikander. "Protecting Against Bidding Down Attacks". Internet Draft draft-montenegro-mipv6sec-bit-method-00.txt (Work In Progress), April 2002. [12] J. Arkko, T. Aura, J. Kempf, V.-M. Mantyla, P. Nikander, M. Roe "Securing IPv6 Neighbor Discovery". Submitted for publication, 2002. J. Arkko et al [Page 7] INTERNET-DRAFT Selection using a hash 24 June 2002 [13] D. Eastlake, P. Jones "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. 12. Author's Address Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland EMail: Jari.Arkko@nomadiclab.com Pekka Nikander Oy LM Ericsson Ab 02420 Jorvas Finland EMail: Pekka.Nikander@nomadiclab.com Gabriel Montenegro Sun Labs, Europe 29, chemin du Vieux Chene 38240 Meylan France EMail: gab@sun.com J. Arkko et al [Page 8]