Security in IP Mobility Solutions Edvard Fonsell Helsinki University of Technology Telecommunications Software and Multimedia Laboratory May 28, 2003

Abstract The number of mobile interfaces grows rapidly, as more and more PDA, mobile phones and other similar devices are connected to the Internet. The current IP solution must be extended to support mobility, which makes security aspect more complex. The nature of mobility arises new security issues, and the complexity makes analyzing them even harder. The purpose of this paper is to discuss how the security issues are resolved in different IP mobility solutions. The analyzed solutions are Mobile IPv4[2], Mobile IPv6[3] and Host Identity Payload (HIP)[4].

1 Introduction The IP mobility raises new security issues. Firstly, the communicating devices may be wireless. This exposes the communication traffic to anyone in the same area, not just those who have access to the wire in a conventional network. Secondly, the devices may move from one wireless network to another. In practice, this means that the IP address of the device changes. In such case, the devices connections should be neither broken nor compromised. Furthermore, the visited network should be protected against malicious wireless devices. Common for both of these issues is that the network may not know anything about the wireless devices before they start communicating with it. In a network where devices have fixed IP addresses, the addresses can be used to identify the device. Having that, the routing takes implicitly care of delivering the packets to the correct device. However, in mobile networks, the IP address of the device may change over time. Thus, the IP address cannot be used to identify the device. The main issue with mobile IP solutions is therefore how to identify and authenticate the devices. After the device is authenticated, conventional methods can be used to secure the rest of the communication. This paper will discuss how Mobile IPv4, Mobile IPv6 and HIP resolve these and other security issues of IP mobility. Each solution is first analyzed separately, and then compared to the others in the end.

1

HUT TML 2003

T-110.551 Seminar on Internetworking

1.1 Scope This paper will address information security properties (confidentiality, integrity and availability) of the IP mobility solutions mentioned before. Other security related properties, such as privacy, will not be addressed. The paper will mostly concentrate on the protecting of the correct functioning of the protocols themselves, not the actual user data. Local security policies, such as providing the access to visiting nodes and protecting the local networks internal resources and traffic, will not be addressed. Functions and security features of common security systems, such as IPsec, will not be analyzed in detail.

2 Mobile IPv4 This section will first briefly explain the basics of Mobile IPv4[2]. After that it will discuss the security issues and features of Mobile IPv4 in more detail. Finally, it will summarize the results.

2.1 Introduction The Mobile IPv4 provides routing of datagrams to mobile nodes in IP version 4[15] networks. The routing is transparent to upper levels. This means that the applications communicating with each other know neither that the other node is mobile nor the actual IP address of it. Mobile IPv4 consists of three main parts, discovering a care-of address, registering the care-of address with the home agent (HA), and tunneling the traffic from HA to the mobile node (MN) through a foreign agent (FA). To maintain the transparency of routing in upper levels, the mobile nodes (MNs) are always identified by their home address. When a MN changes its attachment to the network, it acquires a care-of address from a foreign agent (FA), and registers it with a home agent (HA). The HA then takes care of sending the datagrams destined to the MN through a tunnel to the care-of address. In the end of the tunnel, the FA detunnels the datagrams and sends them to the MN. The datagrams from the MN can be routed directly by the FA, which makes the routing scheme triangular. The main security issue with Mobile IPv4 is the registration of the MN care-of addresses. To ensure correct routing of datagrams, a valid care-of address must always be registered with HA each time the attachment point to the network is changed. This requires strong authentication mechanisms, replay protection and shared secrets between the parties.

2.2 Mobile Node Registration To register a new care-of address with the HA, the MN must send a binding request to it. The message is actually sent to the FA in the visited network, which then forwards it to the HA. The HA either accepts or refuses the request and sends a binding reply with corresponding content to the FA, which again forwards it to the MN. 2

HUT TML 2003

T-110.551 Seminar on Internetworking

If an invalid care-of address was registered with the HA, it would prevent all connections to the MN. Even worse, all packets could be redirected to attacker. To prevent that, MN, FA and HA must authenticate each other. The registration requests and responses must also be protected against replay attack. 2.2.1

Authentication

The purpose of authentication is to verify the identity of originator of the message. Authentication is provided in the Authentication Extension, which contain the type and length of extension, Security Parameter Index (SPI) and a "message digest". The default implementation for calculating the message digest uses HMAC-MD5[13, 14] with 128-bit keys. The data used in the calculation includes the UDP payload of the message, all prior extensions, and type, length and SPI of the Authentication Extension. To maintain backward compatibility with older Mobile IPv4 implementations, the new implementations must also support using MD5 in ”prefix+suffix” mode (keyed MD5) instead of HMAC-MD5. The ”prefix+suffix” mode appends the key to the beginning and to the end of the data that is being authenticated. However, this considered vulnerable to attack. 2.2.2

Replay Protection

The purpose of the replay protection is to prevent the attacker of using registration messages recorded from previous connections. Without protection, the attacker could perform valid but unwanted operations afterwards by resending old messages. Mobile IPv4 defines two different replay protection methods. The first method uses timestamps and is mandatory for all implementations. The second one using nonces is optional. The basic idea of replay protection is to simply add some information to the messages that uniquely identifies the message and can be checked by the receiver. The obvious solution is for the sender to add its current time to the messages. The receiver then checks the timestamp to determine the validity of the message. However, because of latency and clock synchronization problems, the receiver must accept timestamps that are close enough to its own clock. The recommended setting for allowed time difference is 7 seconds, and it should always be greater than 3 seconds. The method also supports resynchronization of clocks in case the validity check fails. Another method uses nonces (random numbers) as unique identifiers. As the FA uses the low-order 32-bits of the identifier to map the messages from HA to MN, the HA must copy them from the registration request to the registration reply. Additionally, the HA generates a new random number and puts it into the high-order 32-bits of the identifier. The MN checks the low-order bits and copies the high-order bits to the next registration request. A new random number must be used for the low-order bits of the new request. When receiving the request, the HA checks the high-order bits against the number that was generated for the last reply. This method also resynchronizes itself automatically.

3

HUT TML 2003

2.2.3

T-110.551 Seminar on Internetworking

Key Distribution

The authentication functions used in Mobile IPv4 require a Security Association, or a shared secret, between the parties. Between the MN and the HA this should not a problem due to the static nature of their relationship. However, the FAs represent a whole different case. When the MN moves to a foreign network and starts interacting with the FA, they might know nothing about each other, not to mention a common shared secret. Thus, an external key distribution system is needed. Authentication, Authorization, and Accounting[17] (AAA) systems, for example DIAMETER[18] and RADIUS[19], provide this kind of functionality. This way it is enough for parties to have a security association with the AAA server, which then operates as a trusted third party authenticating parties to each other. 2.2.4

Random Data

In Mobile IPv4, random data is needed for MD5 keys used in the authentication and nonces used in the replay protection. Both MN and HA must generate MD5 keys properly, i.e. using a good random number generator. If nonces are used in replay protection, HA must generate new nonces for each registration reply. However, MN can copy the high-order bits of the latest registration reply’s identifier generated by the HA to the low-order bits of its next registration request, as long as the nonce is different for each request.

2.3 Address Resolution Protocol The MN uses Address Resolution Protocol[20] (ARP) in the process of acquiring a new care-of address in foreign network. ARP is a protocol that is used to discover a Media Access Control (MAC) address associated to a certain IP address. However, the ARP messages are not authenticated, which makes them vulnerable to attack. Using ARP spoofing[21], an attacker can intercept all traffic between the MN and FN. The attacker sends forged ARP replies to MN and FN, where the MAC address of the requested IP address is replaced with the MAC address of the attacker. The nodes receive the forged replies, and start sending all data destined to the IP address to the attackers MAC address. Thus, the attacker has full control over the traffic between the nodes.

2.4 Summary MN registration needs strong authentication, replay protection and key distribution. The authentication mechanism of Mobile IPv4 is adequate when HMAC-MD5 is used, whereas the MD5 in ”prefix+suffix” mode is not as strong. In both cases the keys must be generated with a random number generator that generates good pseudo-random numbers. Mandatory replay protection method using timestamps is sufficient. The optional method using nonces is also adequate, as long as the nonces are chosen carefully. 4

HUT TML 2003

T-110.551 Seminar on Internetworking

The largest external requirement of Mobile IPv4 security is the key distribution system. AAA systems, such as DIAMETER and RADIUS, can be used to resolve this, but they need to be supported by all parties. However, the node may also have manually set security associations. The vulnerabilities caused by use of ARP are as critical as in the conventional internetworking. This is unfortunate, but not considered as a flaw in the Mobile IPv4 itself even though it is fixed in Mobile IPv6.

3 Mobile IPv6 This section will first briefly explain the basics of Mobile IPv6[3]. After that, it will discuss the security issues and features of Mobile IPv6 in more detail. Finally, it will summarize the results.

3.1 Introduction In IP version 6[16] the mobility support is integrated to the protocol. Moreover, there is no need for FAs, since the Mobile IPv6 is integrated to the IPv6. The features required by the mobility support are mandatory part of the IPv6 specification, so all IPv6 nodes support Mobile IPv6 by definition. As in Mobile IPv4, the MN is always identified by its home address. When MN changes its attachment to the network, it acquires a new care-of address from the network it is visiting. After that, the routing of the traffic can be arranged in two different ways. In the first mode, ”bidirectional tunneling”, a binding update is sent to the HA, which then responses with a binding acknowledgement. After that, the traffic between MN and correspondent node in both directions is tunneled between MN and HA using IPv6 encapsulating, and routed conventionally between HA and correspondent node. In this mode, the correspondent node does not need to support the Mobile IPv6 at all. In the second mode, ”route optimization”, the update also is sent to the correspondent node. Using source and destination address options and routing headers the messages can be directly routed between MN and correspondent node. The advantage of this mode is that the messages can be routed trough the shortest path, and there is no burden to the HA from the communicating. Few security features are needed to ensure the correct function of Mobile IPv6. The Mobile IPv6 specification includes security features for authenticating binding messages and protecting tunnels, home address information, and routing instructions in data packets. These functions need an external key distribution system, random data generation for various purposes and some cryptographic algorithms.

5

HUT TML 2003

T-110.551 Seminar on Internetworking

3.2 Binding Updates Protecting the binding updates is crucial to the correct functioning of Mobile IPv6. As in Mobile IPv4, only the MN itself must be able to update the bindings of care-of addresses. Therefore, the binding messages must be authenticated and protected against replay attacks to prevent malicious nodes from corrupting the binding caches with invalid addresses. In contrast to the Mobile IPv4, the addresses can be bound with both HAs and correspondent nodes. 3.2.1

Authentication

The binding update authentication with HA facilitates IPsec with either Authentication Header (AH) or Encapsulated Security Payload (ESP). The binding update authentication with correspondent node is protected with by return routability procedure followed by correspondent binding procedure. 3.2.2

Correspondent Node Authentication

The return routability procedure uses cryptographic tokens to verify the binding process. Basically, the MN asks the correspondent node to ensure that the MN can be reached from its alleged care-of and home addresses. The correspondent sends test messages to those addresses, and verifies the process only if the MN is able to response to the challenge. After the return routability procedure, the MN constructs a binding management key, Kbm, from various random data and the data gathered during the return routability procedure. The key is then used in the correspondent binding procedure, which creates an entry for the MN in the correspondent node’s binding cache. The binding updates with correspondent nodes are protected against replay by the return routability procedure. The messages used in the procedure have a sequence number and Message Authentication Code (MAC). Messages with invalid sequence numbers are ignored, and tampered messages can be detected by verifying the MAC. 3.2.3

Random Data

Mobile IPv6 uses random data for various keys, nonces, cookies and tokens. Truly random data is very hard to generate, but it is often sufficient to have good pseudo-random data. The point of random data is that the values used can never be guessed based on previous values. The keys used in cryptographic algorithms should always be secret, so practically this is not an issue in that case. However, the nonces, cookies and tokens are typically included in the messages unencrypted. The algorithms may also have certain keys that are known to be weak. Using that kind of keys may compromise the security properties of the algorithm, so they must not be used.

6

HUT TML 2003

3.2.4

T-110.551 Seminar on Internetworking

Cryptographic Algorithms

Mobile IPv6 uses Secure Hash Algorithm version 1[22] (SHA1) to compute hash values and HMAC-SHA1[13] to compute the message authentication codes (MAC). Hash values can be used to check the integrity of the data, i.e. that the data is changed neither accidentally nor intentionally. MACs are used to authenticate messages between parties that share a common secret key. MACs provide a way to send messages unencrypted and encrypt only the hash value with the secret key. The receiver can recalculate the hash value from the message and compare it to the decrypted hash value. If they do not match, either the message is changed or the key used to encrypt the hash value was wrong. Thus, only those who have the secret key can send valid messages to each other. 3.2.5

Key Distribution

The key distribution problems of Mobile IPv6 are definitely easier than the ones of Mobile IPv4. There are no FAs, since all IPv6 nodes support mobility by default. The correspondent node bindings are authorized using Kbm without pre-existing security associations. Key management system such as IKE[23] can be used to establish the security association between HA and MN. However, the nodes must support manual configuration of security associations, whereas supporting automatic key management is optional. Thus, the Mobile IPv6 does not necessarily need key distribution system at all.

3.3 Neighbor Discovery Mobile IPv6 uses IPv6 Neighbor Discovery[24] (ND) instead of ARP to acquire new careof addresses. ND is vulnerable to attacks that cause IP packets to be routed incorrectly. The attacker can utilize this in denial-of-service (DoS) attacks or to read, modify and drop packets. Luckily, the ND supports authentication of the messages by IP Authentication Header. However, to be able to use it the nodes must have a pre-defined security association or support automatic key management.

3.4 Summary Mobile IPv6 has good solutions to most of the security issues of Mobile IPv4. HMACSHA1 is used to create MACs, and MD5 in ”prefix+suffix” mode is not needed anymore even for backward compatibility. Using return routability procedure in replay protection can also be seen as and improvement. Even further, getting rid or ARP and using Neighbor Discovery instead makes the acquiring of care-of address more robust. Thanks to the integration to the IPv6 protocol, the key distribution problem is not so difficult. If the nodes have pre-existing security associations, automatic key management is not needed at all. With HA and MN this might not be a problem, but the authentication of ND messages introduces stronger demand for automatic key management. However, the

7

HUT TML 2003

T-110.551 Seminar on Internetworking

next chapter will address HIP, which provides a different solution to the key management problem.

4 Host Identity Payload This section will first briefly explain the basics of Host Identity Payload[4, 5, 6] (HIP). After that, it will discuss the security issues and features of HIP in more detail. Finally, it will summarize the results.

4.1 Introduction The main purpose of HIP is to separate the identity and location of a host from each other. Currently, IP addresses serve both purposes, which make mobility issues unnecessary complicated. HIP replaces IP as host identifier and leaves the IP addressing and routing intact. Thus, the host can always be identified by its Host Identity (HI) regardless of the IP address it is currently using. HIP is implemented as a new layer between transport and internetworking layers. Thus, HIP requires changes in host kernel at both endpoints of the connection, but not at the routers. Furthermore, the HI may actually be the public key of private-public key pair. This makes the IPsec ESP key exchange fast. Moreover, this solves the problem of external key distribution system. Combined, these properties make mobility issues in HIP almost trivial.

4.2 HIP Protocol Security One goal of HIP is to make the hosts less vulnerable to Denial-of-Service (DoS) and Manin-the-Middle (MitM) attacks. This makes HIP protocol itself a target of similar attacks, only this time the results might be even more damaging to the hosts. However, most of these attacks can be detected and handled by the protocol, at least to some extent. 4.2.1

Denial-of-Service Attacks

DoS is often based on protocols that are easy to initiate but might cause lot of burden to the target. The Host Layer Protocol (HLP), used to initiate HIP connection, is such protocol. HLP can be used to perform DoS attacks in several ways. The first form of the attack can be executed by sending first packets of HLP 4-packet handshake to the target. There is no both efficient and secure solution to this, but the efficiency can be increased by the cost of security. In practice this is done by reusing some results of the processing needed to construct the second packet. The second form uses the third packet of the handshake. The attacker works by the protocol this far, but puts invalid encrypted data or signature to following packets. This takes the responder more effort to find out that the packet is invalid. Again, there is no perfect 8

HUT TML 2003

T-110.551 Seminar on Internetworking

solution, but a counter can be used to ignore all packets of connection after a certain amount of invalid packets. The problem with this solution is that also valid packets might then be dropped. Third form of the attack uses resetting the state of the protocol and the fourth ending of it. However, the HLP is either immune or protected against these. To assure the other endpoint that the state of connection was lost and reset is needed, a system Birthday is added to the second and third packets of the handshake. HIP has no end of state packet, which makes the fourth attack ineffective. 4.2.2

Man-in-the-Middle Attacks

MitM attacker pretends to be the responder for the initiator and initiator for the responder. Without trusted third-party, these kinds of attacks are hard to detect. In HIP, the problem can be handled indirectly. If the parties retrieve each others HIs from a signed DNS zones[25], they can use them to authenticate the handshake packets. However, HIP also supports anonymous HI for the initiator. Doing so, the initiator knowingly risks the MitM attack. Luckily, the responder can choose to decline such connections.

4.3 External Systems HIP uses SHA-1 for calculating hash values. HIP requires some random number generation, where normal rules of generating random numbers apply. HIP may use secure DNS to prevent MitM attacks against the HLP. If HIs are defined as public keys, an algorithm using asymmetric cryptography like DSA[?] may be used. In practice, Secure DSN and DSA are used by current implementations. However, other methods could be used as well.

4.4 Summary HIP achieves its goal of making the hosts less vulnerable to DoS and MitM attacks pretty well. Some forms of the attacks are completely avoided, and the rest have good or adequate solutions, which can also be configured depending on the security level needed. The problem with HIP might be that it does not force the security, even though the security can be achieved when the HIP is configured and used properly. This might lead to a situation where the security cannot be achieved due to interoperability issues. However, this kind of approach has an advantage. The external system used in some operation may become outdated, or a new and better solution may be invented. In such case, the external system could be changed with a reasonable effort. Currently the recommendations suggest using public keys as HIs, DSA for encryption and secure DNS for authentication. These can be considered fairly good solutions, at least for now.

9

HUT TML 2003

T-110.551 Seminar on Internetworking

5 Summary The mobility solutions presented in this paper have two different approaches: extending the existing protocols and solutions, and adding a new protocol layer. The first approach is taken by Mobile IPv4 and Mobile IPv6, whereas HIP represents the second. From the security point of view, the second one seems more promising. This section will do some comparison between the solutions and the approaches they take based on the issues presented in the earlier sections.

5.1 Comparison Mobile IPv4 and its security features are a confusing collection of new protocols and extensions. Analyzing a security of a complex system is hard, and leaves more potential flaws undetected than simple system. In IPv6, the mobility support and some of the security features have been taken into account already in the design phase of the protocol. This makes Mobile IPv6 substantially simpler than Mobile IPv4. However, both of the solutions are tightly tied to the underlying IP addressing and identifying system. This and the backward compatibility issues cause unnecessary complexity to both solutions. On the other hand, HIP has been designed from a scratch. It resolves the mobility issues almost trivially, which makes analyzing and improving its security easy. Additionally, HIP has a simple and fast solution to the key distribution system, which is one of the biggest issues with both Mobile IPv4 and Mobile IPv6. However, HIP requires changes to the kernel, which can definitely introduce new security flaws. It is already clear that Mobile IPv4 will be neither efficient nor secure enough, no matter what external systems are used. The Mobile IPv6 has more potential, but IPv6 is not yet widely adopted. Therefore this could be a good point to rethink the whole thing and implement HIP now when other changes are required anyway.

References [1] IP Routing for Wireless/Mobile Hosts (mobileip) http://www.ietf.org/html.charters/mobileip-charter.html [2] IP Mobility Support for IPv4 http://www.ietf.org/rfc/rfc3344.txt [3] Mobility Support in IPv6 http://www.eecs.wsu.edu/ rgriswol/Drafts-RFCs/draftietf-mobileip-ipv6-19.txt [4] Host Identity Payload Architecture http://homebase.htt-consult.com/ hip/draft-moskowitzhip-arch-02.txt

10

HUT TML 2003

T-110.551 Seminar on Internetworking

[5] Host Identity Payload And Protocol http://homebase.htt-consult.com/ hip/draft-moskowitzhip-05.txt [6] Host Identity Payload Implementation http://homebase.htt-consult.com/ hip/draft-moskowitzhip-impl-01.txt [7] Use of IPSec in Mobile IP http://www.ir.bbn.com/projects/moips/draft-ietf-mobileipipsec-use-00.txt [8] Security Issues in Mobile IPv4 http://caislab.icu.ac.kr/course/2002/spring/ice525/termproject/junglak2.pdf [9] Mobile IP and VPN access http://www.switch.ch/mobile/WS1/SecMIP_SwitchMobile.pdf [10] Mobile networking through Mobile IP http://www.computer.org/internet/v2n1/perkins.htm [11] Securing a Mobile Internet http://www.eurescom.de/ public-webspace/P900series/P912/Papers/ Securing%20a%20Mobile%20Internet.doc [12] Introduction to HIP http://www.tml.hut.fi/ pnr/publications/NDSS03-Nikanderet-al.pdf [13] HMAC: Keyed-Hashing for Message Authentication http://www.ietf.org/rfc/rfc2104.txt [14] The MD5 Message-Digest Algorithm http://www.faqs.org/rfcs/rfc1321.html [15] Internet Protocol http://www.faqs.org/rfcs/rfc791.html [16] Internet Protocol, Version 6 (IPv6) Specification http://www.faqs.org/rfcs/rfc2460.html [17] Authentication, Authorization and Accounting (aaa) http://www.ietf.org/html.charters/aaa-charter.html [18] Diameter http://www.diameter.org/ [19] Remote Authentication Dial In User Service (RADIUS) http://www.ietf.org/rfc/rfc2865.txt?number=2865 [20] An Ethernet Address Resolution Protocol http://www.faqs.org/rfcs/rfc826.html 11

HUT TML 2003

T-110.551 Seminar on Internetworking

[21] An Introduction to ARP Spoofing http://chocobospore.org/projects/arpspoof/arpspoof.pdf [22] SHA1 Secure Hash Algorithm - Version 1.0 http://www.w3.org/PICS/DSig/SHA1_1_0.html [23] The Internet Key Exchange (IKE) http://www.ietf.org/rfc/rfc2409.txt [24] Neighbor Discovery for IP Version 6 (IPv6) http://www.faqs.org/rfcs/rfc2461.html [25] Domain Name System Security Extensions ftp://ftp.is.co.za/rfc/rfc2535.txt [26] Digital Signature Standard (DSS) http://www.itl.nist.gov/fipspubs/fip186.htm

12