Network Working Group Jari Arkko
INTERNET-DRAFT Pekka Nikander
Category: Standards Track Ericsson
<draft-arkko-mipv6-select-hash-00.txt> 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 <draft-
arkko-mipv6-select-hash-00.txt>, 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]