Aug 31, 2006 - host authentication, payload encryption, and a cryptographic namespace ...... The HMAC verification is very cheap in terms of CPU cycles. ...... graphic Techniques on Advances in Cryptology, pages 369â378, London, UK,.
Universität Tübingen Wilhelm-Schickard-Institut für Informatik
Protokoll-Engineering & Verteilte Systeme
LHIP – Lightweight Authentication for the Host Identity Protocol Diploma Thesis (Diplomarbeit) Junior Research Group on Distributed Systems Chair for Computer Networks and Internet Wilhelm-Schickard-Institute for Computer Science University of Tübingen by cand. inform. Tobias Martin Heer
Advisor: Dipl. -Inform. Stefan Götz MS CS Miika Komu Prof. Dr. Klaus Wehrle Dr. Andrei Gurtov Prof. Dr. Georg Carle
August 31st, 2006
I hereby declare that this submission is my own work and that, to the best of my knowledge and belief, it contains no material previously published or written by another person nor material which to a substantial extent has been accepted for the award of any other degree or diploma of a university or other institute of higher learning, except where due acknowledgment has been made in the text. Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Tübingen, den 29. August 2006
Acknowledgements I want to thank all the people who have supported me in creating and completing this work. First of all I want to thank Andrei Gurtov and all the members of the InfraHIP project for giving me the opportunity to work on this topic. Special thanks go to Miika Komu who advised the practical part of this thesis. I thank him for his professional and personal support. He made the dark winter in Helsinki a lot brighter! A big "thank you" goes to Andrey Khurri for his help with HIP on the Nokia 770. Many thanks to all the other people in the infraHIP project and all the members of the Helsinki Institute for Information Technology who supported me with insight into HIP and the HIP for Linux implementation: Teemu Koponen, Diego Beltrami, Sasu Tarkoma, and all the others who are not mentioned here. A big THANK YOU also goes to my supervisors in Germany. Special thanks to Stefan Götz for the remote support over Skype while I was in Finland and when I was back. I am grateful for all his help in writing this thesis and I am glad he did not go nuts when finding the same typo dozens of times. I also thank him for always being available 24-7! Also, I thank Prof. Klaus Wehrle for giving me the opportunity to write this thesis. I specially thank him for paving the way to Finland. Many thanks to Olaf Landsiedel as well for visiting me with Stefan in Helsinki and for many interesting discussions on and off the topic. I also want to thank Jukka Ylitalo for the fruitful e-mail correspondence about the WIMP protocol and the interactive hash chain approach. None of this would have been possible without Prof. Georg Carle of the department of Computer Networks who allowed me to write this thesis under his supervision. I thank the Deutscher Akademischer Austausch Dienst DAAD for giving me a scholarship during my time in Finland, without which my stay in Helsinki would not have been possible. This work is dedicated to my spouse Melanie and my son Jannik who was born while I was writing this thesis. They supported me with all their love and patience while I was in Finland and when I was finishing the thesis here in Germany.
Abstract The ubiquity of truly mobile appliances such as Wi-Fi-enabled mobile phones, PDAs, and Internet web pads stands in stark contrast to the lack of mobility support in today’s communication protocols. Many of these devices are multihomed and use standard protocols like IP and TCP, which have been designed for non-mobile computers with a single network device. Therefore, they are not able to cope with mobility and multihoming appropriately. Several protocols and protocol extensions have been proposed in order to add mobility support to TCP/IP. One of the most promising among them is the Host Identity Protocol (HIP) which adds an additional protocol layer between TCP and IP to hide host mobility from the transport layer. Apart from mobility and multihoming support, HIP also supports host authentication, payload encryption, and a cryptographic namespace without requiring changes to the network infrastructure or network applications. Especially mobile devices with few CPU resources are slowed down by HIP. The poor performance of HIP on these mobile devices results from the extensive use of public-key cryptography for securing the main HIP protocol functions. These public key operations are complex and CPU intensive. In this thesis, we present Lightweight HIP (LHIP), a HIP protocol extension which enables HIP to offer mobility and multihoming support without the use of public key cryptography. The goal of LHIP is to speed up HIP in order to make it usable for weak mobile devices.
Contents
1
2
Introduction
1
1.1
Challenges for Mobile TCP/IP . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
2
The Host Identity Solution . . . . . . . . . . . . . . . . . . . . .
Background
5
2.1
The Host Identity Protocol . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
A New Namespace . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.2
A New Protocol Layer . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.3
HIP and IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.4
Base Exchange - the HIP Handshake . . . . . . . . . . . . . . . .
13
2.1.5
DoS Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.1.6
HIP Control Channel . . . . . . . . . . . . . . . . . . . . . . . .
18
2.1.7
HIP and Middleboxes . . . . . . . . . . . . . . . . . . . . . . .
20
2.1.8
Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.1.9
The Double Jump Problem . . . . . . . . . . . . . . . . . . . . .
22
2.1.10 Closing a HIP Association . . . . . . . . . . . . . . . . . . . . .
23
Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.2.1
Symmetric Cryptography . . . . . . . . . . . . . . . . . . . . . .
23
2.2.2
Public-Key Cryptography . . . . . . . . . . . . . . . . . . . . .
23
2.2.3
One-Way Cryptographic Hash Functions . . . . . . . . . . . . .
27
2.2.4
One-time Signatures . . . . . . . . . . . . . . . . . . . . . . . .
29
2.2.5
Time-Based Signatures . . . . . . . . . . . . . . . . . . . . . . .
30
2.2.6
Interactive Signatures Based on Hash Chains . . . . . . . . . . .
31
Weak Authentication Techniques . . . . . . . . . . . . . . . . . . . . . .
33
2.2
2.3
ii 3
Contents Problem Analysis
35
3.1
Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.1.1
Test Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.1.2
Performance of the DH Key Exchange . . . . . . . . . . . . . . .
36
3.1.3
RSA and DSA . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.1.4
Hash Functions and HMAC . . . . . . . . . . . . . . . . . . . .
38
3.1.5
Performance of HIP . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2
Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.3
Lightweight HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.1
Scope of LHIP . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.2
Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
HIP High-level Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.4.1
LHIP High-level Goals . . . . . . . . . . . . . . . . . . . . . . .
44
Possible Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.5.1
Remove Diffie Hellman . . . . . . . . . . . . . . . . . . . . . .
45
3.5.2
Remove DSA/RSA . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.5.3
Reduction of the Key Size . . . . . . . . . . . . . . . . . . . . .
47
3.5.4
LHIP Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.4
3.5
4
Design
49
4.1
Hash Chains for HIP Authentication . . . . . . . . . . . . . . . . . . . .
50
4.1.1
One-time Signatures . . . . . . . . . . . . . . . . . . . . . . . .
50
4.1.2
Time-Based Hash Chain Signatures . . . . . . . . . . . . . . . .
51
4.1.3
Interactive Approach . . . . . . . . . . . . . . . . . . . . . . . .
51
LHIP Authentication Layer . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.2.1
Improved IHC Signatures . . . . . . . . . . . . . . . . . . . . .
52
4.2.2
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.2.3
State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.2.4
HIP Integration . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
LHIP Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.3.1
LHIP Base Exchange . . . . . . . . . . . . . . . . . . . . . . . .
70
4.3.2
Mobility and Multihoming Updates . . . . . . . . . . . . . . . .
74
4.3.3
LHIP Interaction with Middleboxes . . . . . . . . . . . . . . . .
76
4.2
4.3
Contents
iii 4.3.4
4.4
4.5
5
6
Closing an LHIP Association
. . . . . . . . . . . . . . . . . . .
78
Namespace Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.4.1
Attacks Without Namespace Protection . . . . . . . . . . . . . .
79
4.4.2
Defense Mechanisms . . . . . . . . . . . . . . . . . . . . . . . .
80
4.4.3
State Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
Association Upgrades: From LHIP to HIP . . . . . . . . . . . . . . . . .
82
4.5.1
Second HIP Transform . . . . . . . . . . . . . . . . . . . . . . .
82
4.5.2
Upgradable Associations . . . . . . . . . . . . . . . . . . . . . .
82
4.5.3
Upgrade Process . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Implementation
87
5.1
The HIP Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.1.1
Packet Handlers . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.1.2
State Centric Design . . . . . . . . . . . . . . . . . . . . . . . .
91
5.1.3
LHIP State . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
5.1.4
Authentication Layer . . . . . . . . . . . . . . . . . . . . . . . .
92
5.1.5
State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.1.6
Hash Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.1.7
Modifications of the Base Exchange . . . . . . . . . . . . . . . .
94
5.1.8
NULL Encryption and the Missing Shared Secret . . . . . . . . .
94
5.2
Hipconf Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.3
Socket Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.4
State of the LHIP Implementation . . . . . . . . . . . . . . . . . . . . .
95
Evaluation and Discussion
97
6.1
Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
6.1.1
Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
6.1.2
Test Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
6.1.3
HIP and LHIP Base Exchange . . . . . . . . . . . . . . . . . . .
98
6.1.4
HIP and LHIP Update . . . . . . . . . . . . . . . . . . . . . . . 105
6.1.5
LHIP to HIP Upgrade . . . . . . . . . . . . . . . . . . . . . . . 107
6.1.6
HIP and LHIP Close Process . . . . . . . . . . . . . . . . . . . . 108
6.2
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
iv
7
Contents 6.2.1
LH1 - Performance . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.2.2
LH2 - Protocol Security . . . . . . . . . . . . . . . . . . . . . . 109
6.2.3
LH3 - Namespace Security . . . . . . . . . . . . . . . . . . . . . 109
6.2.4
LH4 - Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2.5
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Summary and Outlook
References
111 113
1. Introduction Today, the TCP/IP protocol suite is probably the most popular network protocol suite. It ties the Internet together by making hosts and applications addressable and offers packetand stream- based communication between applications. It is the main protocol suite of the Internet and it is used by most networking computers. Unfortunately, TCP/IP has been developed and widely deployed long before mobile communication devices like Notebooks, Personal Digital Assistants (PDAs), and Smartphones have surfaced. It was designed for stationary hosts with a single and fixed point of network attachment. It is not surprising that this leads to shortcomings when TCP/IP is used on mobile devices. Mobile communication devices are small portable computers with wireless communication facilities. Users can move around with these mobile devices while they are communicating. These mobile devices are not just physically mobile. They also change the network they are attached to, when the user leaves the range of one wireless network and enters the range of another. This means that they change their point of network attachment. This is called host mobility. Moreover, many of these devices use several network interfaces – even at the same time. This ability is called multihoming. TCP/IP does not support either mobility or multihoming. The shortcomings of TCP cause problems when it is used on mobile devices. Due to the widespread deployment of TCP/IP, the prevalent Internet infrastructure, which relies on the Internet Protocol (IP), and a multitude of existing applications which use TCP/IP, the use of the TCP/IP protocol suite on mobile devices is still nevertheless desirable. However, various challenges must be solved before TCP/IP is fit for use with mobile devices.
1.1
Challenges for Mobile TCP/IP
When TCP/IP was designed, network computers were big, heavy, dependent on external power support, and connected to networks with wires. Hosts were stationary. As hosts were not mobile, it was sufficient for TCP/IP to identify a host by its location. The location of a host provided all the information which was necessary to address a host and to route packets towards it. Hence, the network-layer identifiers, i.e., the IP addresses, were used
2
1. Introduction
to address host as well as to express its topological location in the network. This point of view was valid as long as hosts were stationary. This means that they only have one point of network attachment and this point of network attachment is fixed. Every host has an identity which makes it distinct from other hosts. The identity is abstract and it can not be taken from the host. The identity is expressed in form of an identifier. The identifier allows other hosts to refer to a hosts identity. In TCP/IP, IP addresses are used as identifiers. IP addresses, therefore, provide information about the identity of a host. Mobile hosts change their IP addresses while they move from network to network. It is clear that the identity of a host should not change just because it is moving. The host must, nevertheless, change its IP address because the address must reflect the change of location and provide the necessary routing information to the network. As TCP/IP cannot handle this situation, the usual result of host mobility are broken transport-layer connections and undeliverable packets. For mobile hosts, the dual use of IP addresses as topological locators and identifiers, makes relocation and sustaining existing connections impossible. Another challenge are hosts with several network interfaces which are connected to different networks. Multihomed hosts have several IP addresses. As TCP/IP uses IP addresses as identifiers, traffic from the different interfaces of one host is not distinguishable from traffic from different hosts. Again, the use if IP addresses as identifiers and topological locators complicates the authentication conditions for multihomed hosts. IP addresses are only weak identifiers for hosts. They identify a host by its location information but this location information can be forged. They change whenever a host changes its location and, therefore, its IP address. After such a change, the communication peer of this host must have a way to verify that it is still communicating with the same host as before. Mobile hosts with changig IP addresses require other ways of identification. This way of authentication has to be stronger than a simple verification of the locator of a host in order to prevent attacks. Otherwise any host could impersonate another host. Impersonation is the process of spoofing a host’s identifier to make other hosts believe they are communicating with the host while they are actually communicating with a malicious attacker. When hosts move from network to network, the security properties of the networks may differ from earlier ones. Public hotspots, which are reachable over wireless links, provide considerably less security than a wired private network. Encryption and signatures are measures to ensure the confidentiality and authenticity of transferred data. Unfortunately, the initial design of the TCP/IP protocol was rather tuned for performance and scalability than for security. The TCP/IP suite does not support either encryption or signatures inherently. The demand for solutions to mobilize TCP has led to various different approaches. Among these solutions are mobile IP [rfc96], the Internet Indirection Infrastructure (i3) [SAZ+ 02], mSCTP [CLK04], shim6 [NB06], and the Host Identity Protocol (HIP) [MNJH06].
1.1.1
The Host Identity Solution
The Host Identity Protocol tackles the problems stated above by introducing a new namespace. This namespace makes hosts addressable by unforgeable identifiers. This enables TCP/IP to use IP addresses as pure locators and to address hosts, independently of their
1.1. Challenges for Mobile TCP/IP
3
location, by the Host Identity (HI). HIP also utilizes existing security protocols and algorithms to secure traffic. It uses Public Key (PK) cryptography to authenticate hosts and symmetric cryptography to encrypt and authenticate traffic. Unfortunately, public key cryptography is costly in terms of CPU usage. The additional overhead for public key cryptography is a burden for weak devices like mobile phones. Consequently, HIP slows down the connection establishment on these mobile devices. Especially when applications require neither security nor authentication, the overhead introduced by HIP is not acceptable. Our contribution is to determine the performance impact of HIP on weak devices and to address the problem of expensive cryptography. We replace the heavyweight cryptographic algorithms by lightweight alternatives. To achieve this, we introduce a new lightweight authentication layer, based on hash chains. We also reduce the use of public key cryptography to an extent which is absolutely necessary in order to enable mobility but still guarantee safety. Our lightweight HIP approach speeds up the connection establishment phase and the mobility update process on mobile hosts and makes HIP applicable to CPU poor devices.
4
1. Introduction
2. Background This work is based on the Host Identity Protocol. It modifies the HIP handshake and the authentication mechanisms. Furthermore, the cryptographic components of HIP, the Diffie Hellman (DH) key exchange, the Hashed Message Authentication Code (HMAC), and RSA [RSA77] and DSA [Nat00] signatures are examined in detail. LHIP uses hash chains as cryptographic alternatives to the DH key exchange in order to reduce the computational complexity of the HIP protocol. This chapter gives an introduction to HIP and discusses the cryptographic primitives used in HIP and our lightweight version of HIP.
2.1
The Host Identity Protocol
The following pages give an overview of the Host Identity Protocol. The HIP protocol is described in the HIP base draft [MNJH06]. Its extensions are specified in a number of IETF documents which handle topics like mobility and multi-homing [Hen06], NAT traversal issues [SPK+ 06], HIP IPsec handling [MJN06] and DNS-related issues [NL06]. The Host Identity Protocol provides mobility support for the TCP/IP protocol suite. It is currently being standardized by the IETF. Two IETF groups, the HIP working group and the HIP research group, are working on the protocol details. The goal of HIP is to provide end-host mobility in a safe and decentralized fashion. In contrast to mobile IP, no home agents or third party hosts, are needed to support basic host mobility. HIP provides host authentication and secure communication for mobile hosts. The HIP protocol architecture is described in RFC 4423 [rfc06].
2.1.1
A New Namespace
The lack of an unique host identifier, which even sustains host mobility, limits the usability of existing networking applications on mobile hosts. HIP introduces a new namespace to provide every host with at least one statistically and globally unique identifier in order to address a host independent of its location. This identifier is called Host Identifier (HI). 2.1.1.1
Role of IP Addresses in TCP/IP
The Internet Protocol uses IP addresses to encode the location of a host. This address identifies the point of network attachment of a host. Moreover, it provides information
6
2. Background
for the network infrastructure which is needed to route packets towards the host. The IP address is also used to identify a host at the network, transport, and application layers1 . The IP address fulfills this dual role well, as long as hosts are immobile and, therefore, do not change their point of network attachments. Overloading of IP addresses to express location and identity becomes problematic as soon as end-host mobility comes into play. On the one hand, it is necessary to change the IP address of a host whenever a node changes its point of network attachment. On the other hand, the IP address is used to identify the host. Due to the dual usage, changing the IP address implies a change of the host’s identifier. This conflict causes transport layer connections and network applications, which deal with IP addresses, to break whenever the host or its peer moves. The term peers refers to the two communicating hosts. The peer of a host is the host which it communicates with. A change in the network attachment of a host leaves its peers with outdated network addresses which point to its old point of network attachment. The network routes all data a peer sends to the host to the previous location of the host. Moreover, the applications on the mobile host uses the obsolete IP address which is problematic whenever the application passes the address on as referral to itself. These problems can be solved by mobility-aware applications, which handle mobility at the application layer. However, this increases the complexity of the applications and requires every application to define an application specific solution. A generic solution at a lower level is preferable. It makes mobile networking available for all applications, regardless of whether they have been designed to support end-host mobility or not. Unlike approaches like i3, which use overlay networks and a new namespace in order to support host mobility, HIP does not introduce a new routing layer. The IP protocol is still used directly for packet delivery, which gives HIP a similar performance as IP has. The dual role of IP addresses is not only problematic for mobile hosts. Hosts which are connected via several network interfaces at the same time are addressable by several IP addresses. Each of the network interfaces has its own IP address and, therefore, its own identifier. Shifting traffic from one interface to another or using alternative interfaces, in case of failures, is not possible because applications directly deal with IP addresses. Again, the lack of an unique address to identify a host with multiple network interfaces complicates multihoming and requires multihoming-aware applications. 2.1.1.2
Host Identifiers
The Host Identity Protocol introduces a new namespace in order to remove the IP addresses from their dual role. This namespace is called the host identity namespace. Every host selects one or more statistically unique names from the namespace. These host identifiers are used in order to address a host independent of its location. With the host identity in place, the IP address of a host acts as pure locator and may change at any time. The HI, on the contrary, stays the same, regardless of the host’s location. The IP address is only used by the network layer while the transport layer and all upper layers use the HI. This decoupling hides host mobility from the transport layer and all 1 Many applications use their own application specific namespace. Nevertheless, the IP address is often used by applications directly. Popular examples are web browsers, FTP clients and SSH terminals. These applications usually accept both, Uniform Resource Identifiers (URIs) and IP addresses. The URIs are usually resolved to IP addresses, using the Domain Name System (DNS).
2.1. The Host Identity Protocol
7
upper layers. It enables host mobility for applications which have not been designed for mobile hosts. The dual role of the IP address is split into IP addresses as locators and HIs as identifiers. Using plain meaningless identifiers would lead to new possibilities for Denial of Service (DoS) attacks on these identifiers. These attacks would be worse than today’s attacks on IP addresses as attacks on IP addresses usually require the attacker to be in a certain network location. HIP must provide ways to ensure that only the host which owns an HI can use it. Public-Key (PK) cryptography provides an elegant solution for this problem. HIP uses public keys as HIs. A host can use the corresponding private key to prove that it is the legitimate owner of the HI. The public keys used as HIs are either RSA or DSA keys. HIP hosts must support RSA HIs and may support DSA HIs. Therefore we focus on RSA. However, in case both hosts support DSA, it may be used as an alternative. Using public keys as identifiers creates a cryptographic namespace and protects hosts from identity theft and impersonation. This cryptographic namespace enables trustworthy communication between hosts without relying on volatile IP address assignments for host identification. 2.1.1.3
Host Identity Tags
The length of the host identity is determined by the strength of the PK pair. A typical key-length for an HI is 1024 bits. The length of the HI makes it impractical to use use HIs as identifiers in packets and as identifiers for the transport and application layer. HIP uses the Host Identity Tag (HIT), which is a 128-bit long hashed encoding of the HI, instead. The application of a cryptographic hash function tightly couples the HIT and the HI. The HIT is suitable as trustworthy reference to the actual host identifier. Using HITs instead of HIs has three advantages. Firstly, applications can deal with HITs because they are of the same length as an IPv6 address. It is backwards compatible and, therefore, enables HIP unaware applications to use HIP. Secondly, using HITs instead of HIs decreases the HIP packet size. Thirdly, the HIT provides a fixed-sized format for APIs, which the different public key lengths can not provide. The full representation of the HI is only needed for host authentication during the HIP handshake. The HIT consists of a 28-bit prefix, which is used to mark it as non-routable IPv6 address, and a 100-bit hash of the public key. That way, HITs are distinct from IPv6 addresses. The HI creation process uses the Secure Hash Algorithm SHA-1 [Nat95] as cryptographic hash function in order to generate the hash of the HI. The hash output is truncated to 100 bits. The hash function is collision-free which makes it infeasible for attackers to find another host identity with the same HIT. In the rare case that two host identifiers map to the same HIT, the actual host identity and the possession of the private key distinguishes the hosts. 2.1.1.4
Local Scope Identifiers
Legacy applications that are hardcoded to use IPv4 addresses can not use HITs because of the limited size of IPv4 addresses. These addresses are only 32 bits long and, therefore, not suitable as secure identifiers. HIP uses Local Scope Identifiers (LSIs) to maintain compatibility with IPv4 and other APIs and applications which expect IPv4 type addresses as identifiers. An LSI is a 32-bit identifier which is only valid in a local scope. It is the
8
2. Background
local representation of a HIT. The HIP protocol can resolve LSIs into HITs. An LSI is not suitable for referrals since it can not be passed forward to other hosts because of its local scope. 2.1.1.5
Host Identifier Resolution
A name resolution infrastructure is needed in order to map HIs to IP addresses. This name resolution can either be provided by the DNS service or other name lookup structures like Distributed Hash Tables (DHTs). Nikander et al. have proposed a solution based on the Internet Indirection Infrastructure (i3) [NAO04]. i3 provides a DHT-based lookup service for HITs and resolves them to IP addresses. A host requires the services of the name resolution infrastructure in the beginning of the HIP handshake. It must learn about the IP address of its peer in order to establish a HIP association. During the lifetime of a HIP association, name resolution is only needed for the initial contact or if both hosts change their location simultaneously. 2.1.1.6
Protection against MITM attacks
A man-in-the-middle (MITM) attack takes place if an attacker is located on the network path between two hosts. Such an attacker can modify and destroy packets. MITM attacks are an efficient way to compromise PK technologies. The MITM does not try to calculate the private key to a public key. Instead, it replaces the public keys of the communicating peers in the handshake packets with its own public keys. Both peers, therefore, establish a security context with the attacker. The attacker forwards all packets to the peers. This enables him to act exactly like the peers would. The MITM attacker can, therefore, read all packets exchanged between the peers, in cleartext. A detailed description of MITM attacks is provided in [Wät04]. HIP makes MITM attacks impossible. The coupling between cryptographic key, HI and HIT assures that only the owner of an identifier can use it. An MITM attacker can not replace the cryptographic keys in the packets because the MITM’s keys would not match the identifiers.
2.1.2
A New Protocol Layer
HIP provides its services between the network and the transport layer. It translates the HITs, which are used by the transport and upper layers, to IP addresses, which are used by the network layer. Thus, TCP and UDP keep their properties even after a host changes its point of network attachment. The transport layer protocols are unaware of the host mobility. Figure 2.1 illustrates the translation between HIs and IP addresses above the network layer. The HI-to-IP address translation below the transport layer has the advantage that TCP connections do not break after host mobility2 . Measures like the TCP slow start algorithm [Ste97], for new connections, do not slow down the data traffic after a mobility event as would be the case if the TCP-session would need to be re-established. The congestion control of TCP stays operative for the connection and enables adaption to different network capacities after location changes. 2 This is only true if the time for the vertical handover between the networks is shorter than the time until the transport layer connections time out.
2.1. The Host Identity Protocol
9
Figure 2.1: The host identity layer extends the TCP/IP stack between transport and network layer. It translates IP addresses into HIs and vice versa. Figure 2.1 shows where the HIP-layer is located. The upper layers use HIs to identify hosts while the network layer uses IP addresses to deliver packets. The HIP layer exchanges the HIs with IP addresses and sends the packets to the network. The Packet headers in figure 2.1 show where HIs and IP addresses are used. The payload of each layer is marked grey. Payload refers to the data which is handed over to a protocol from the upper layers. The HIP-layer updates the mappings between HIs and IP addresses whenever a host changes its location. The upper layers are not concerned with locator changes because they use HIs, which stay the same in case of IP address changes. Neither the functionality of the network nor the transport layer requires modification in order to support HIP.
2.1.3
HIP and IPsec
Typically, but not necessarily, HIP protects the payload traffic between two communicating hosts by utilizing IPsec. HIP treats all data which is sent by the transport and the upper layers as payload. IPsec is the security architecture for the TCP/IP protocol. IPsec provides confidentiality, authenticity and integrity for the Internet Protocol. IPsec is specified in RFC 1825 [Atk95b]. Encryption of IP packets with IPsec is managed by the Encapsulated Security Payload (ESP) protocol [Atk95a]. The way in which HIP interacts with IPsec is specified in [Mol99]. Utilizing IPsec for payload encryption reduces the complexity of the HIP protocol, increases its performance, and maintains compatibility with existing IPsec-aware
10
2. Background
Figure 2.2: The ESP transport formats and their header structure. middleboxes like firewalls or Network Address Translation (NAT) middleboxes. The following section gives a short overview of IPsec and the way HIP utilizes IPsec. IPsec Security Policies and Security Associations According to RFC 2401 [KA98], IPsec security associations are simplex connections which afford security services to the traffic carried by them. Two security associations are required to secure duplex communication between hosts. Among other information, the SA consists of information about the IP address of the remote host, the IPsec protocol which is used to transmit the payload, the encryption and authentication algorithms, and the keys which are used. Security Policies (SP) determine which services are offered to IP datagrams and in what fashion they are offered. They also define which kind of security mechanisms, and protocols, are to be used. Each encrypted packet contains a Security Parameter Index (SPI), which identifies the right security context on the destination host. Every security association uses a different SPI. Therefore, both hosts must agree on two SPIs in order to send data back and forth. HIP uses the Encapsulated Security Payload (ESP) protocol to protect the upper-layer payload. ESP Modes The ESP protocol provides data confidentiality, data authentication, and protection from replay attacks. The payload is protected by symmetric encryption which renders the packet
2.1. The Host Identity Protocol
11
payload useless for an attacker that does not possess the secret key. The ESP protocol defines two modes of operation. The tunnel mode encapsulates the whole IP packet and adds a new IP header while the transport mode adds the ESP header between the IP and the TCP header and uses the IP header of the original packet. A third transport mode which makes implementing HIP easier was proposed by Nikander and Melen [NM06]. The Bound End-to-End Tunnel mode (BEET) is currently being standardized. Figure 2.2 shows three different ESP transport modes. The transport mode is used when traffic between two endpoints has to be protected. It does not encrypt the IP header but only the transport layer payload. The IP protocol uses the address information in the IP header to deliver the packet. The tunnel mode is mainly used to connect networks securely through security gateways. Not the communication endpoints but two intermediate gateways have established an IPsec association. The traffic is tunneled between these middleboxes. The tunnel mode adds an additional IP header in front of the ESP header. The receiving gateway, e.g., the endpoint of the tunnel, removes this header and forwards the unencrypted packet to its actual destination. Bound End-to-End Tunnel Mode The BEET mode offers semantics similar to the tunnel mode with a transport mode packet format. This decrease in packet size is reached by an additional network address translation step on the tunnel endpoints. The outgoing gateway replaces the destination IP address of the packet with the IP address of the incoming gateway. The payload is encrypted and sent to the other tunnel endpoint. The incoming gateway decrypts the packet and changes the IP address of the packet to the IP address of the destination. This replacement procedure requires both tunnel endpoints to maintain a mapping between the SPI in the ESP packets and, i.e., the security context, and the destination IP address. Figure 2.2 shows the BEET mode. The IP addresses of the communicating peers are marked in blue while the IP addresses of the tunnel endpoints are marked in red. During the encryption process, IPsec replaces the IP addresses of the source and destination host with the IP addresses of the tunnel gateways. The receiving gateway reverses this address translation and restores the original source and destination addresses before it delivers the packet to the destination host. The BEET mode can be used to implement HIP payload encryption in a very efficient way. The HITs are used as source and destination IP addresses while the actual IP addresses of the hosts are the tunnel endpoints. This means the hosts and the gateways are on the same network node. The tunnel is used for encrypted IP packet delivery while the translation maps the IP addresses to the corresponding host identifiers. The BEET mode handles all aspects that are necessary to transport HIP-related application payload. It handles the encryption and decryption process and manages the translation between HITs and IP addresses. It is sufficient for the HIP protocol to set up the security policies and security associations for the BEET mode and to modify them in case of host mobility. The HIP protocol is not required to handle payload itself. It fully delegates this task to the ESP and the BEET mode. Figure 2.3 gives a detailed overview of the relations between HIP and IPsec. Two hosts, host A with the IP address IP-A and HIT HIT-A and host B with the IP address IP-B and
12
2. Background
Figure 2.3: HIP utilizing IPsec. Two hosts have established a HIP association and an IPsec association. The payload is encrypted by IPsec while the HIP control messages are handled by HIP. HIT HIT-B, have established a HIP association. The payload is encrypted by IPsec. IPsec handles the address translation from HIT to IP address and back, too. The encrypted ESP packets contain an SPI which indicates the security context for packet decryption. The grey arrows show the interaction between IPsec and HIP software modules. HIP sets up the security policies and security associations and retrieves the SPI values from IPsec.
2.1. The Host Identity Protocol
13
Figure 2.4: Simplified scheme of the base exchange. The incoming SPI value of the peer is needed to set up the security associations. Both hosts have to exchange the SPI values during the base exchange. Each host needs the SPI value of its peer in order to set up its outgoing SA. HIP carries these SPI values in the ESP info parameters. HIP maintains full control over the IPsec tunnel and can modify the tunnel endpoints whenever a host changes its IP address.
2.1.4
Base Exchange - the HIP Handshake
In order to use HIP for unicast Internet communication, two hosts must establish a HIP association. This association comprehends all properties and aspects which constitute the HIP communication context between two hosts. A HIP association has a certain lifetime during which both hosts share a communication context. Both peers can communicate, using HIP, during the lifetime of the association. Two hosts establish the HIP association during the HIP handshake, the so-called Base EXchange (BEX). The base exchange consists of four packets. The purpose of the handshake is to authenticate the hosts, to establish the HI-to-IP address mapping, to create a shared secret, which can be used for symmetric encryption and authentication. All HIP control messages carry the HIP header which always contains the IP addresses and the HITs of both hosts. Depending on the packet type or protocol extension, additional information and parameters can be attached to the HIP header. The first message initiates the exchange while the other three messages trigger the creation of a shared secret with
14
2. Background
an authenticated Diffie Hellman (DH) key exchange [DH76] and to set up an encrypted tunnel. Details on the Diffie Hellman public-key algorithm can be found in section 2.2.2.1. During the base exchange, the host which requests a connection is called initiator. The host which responds to the initiator is called the responder. These roles do not apply after the base exchange. The initiator is usually a client while the responder usually acts as server because both client and server may initiate further exchanges of packets. 2.1.4.1
First Initiator Packet
The first initiator packet (I1) initiates the BEX. The sole purpose of the I1 packet is to inform the responder that the initiator requests a HIP association. This packet carries only little information and is not protected by authentication mechanisms. The absence of authentication mechanisms is a precaution to prevent DoS attacks which aim at the consumption of CPU power at the responder, using PK operations. The I1 packet only indicates that a host is going to establish a HIP association and it determines which HITs and which HIs, respectively, should be used for the association. 2.1.4.2
I1 Processing
The responder may but does not have to establish any state on receipt of the I1 packet. It only sends back a first responder packet (R1) and creates state later. Delaying the process of state establishment protects the initiator from attackers which generate a flood of I1 messages in order to deplete resources on the responder. The R1 packet contains the HI of the responder and a DH public key. The R1 packet, therefore, initiates the DH key exchange. 2.1.4.3
The First Responder Packet (R1)
HIP and IPsec support several different symmetric encryption and authentication algorithms. Both peers must agree on a set of algorithms which should be used during the HIP association. These sets are called transform suite. The R1 packet contains a HIP transform parameter which lists the transform suites supported by the responder. Preferred transform suites are listed first in the parameter. The R1 packet also contains a puzzle which slows down attackers in case of a DoS attack. The puzzle is a cryptographic challenge which the initiator must solve before costly PK operations are performed by the responder. The difficulty of the puzzle can be set by the responder. The difficulty parameter determines how much computing power is required to solve the puzzle. Puzzle difficulties of zero allow the initiator to skip the puzzle processing. The responder may also add an R1 generation counter parameter to the packet. This generation counter indicates the freshness of an R1 message. Moreover, the responder may add an echo request parameter. This parameter contains data which the initiator has to send back to the responder. The responder can use the echo request to store encoded data in the R1 packet. This supports responders in delaying their point of state establishment. The responder, however, may use this parameter for any other purpose as well. The contents of the echo request parameter are only meaningful for the responder. The initiator copies them to the I2 packet and does not interpret them in any way.
2.1. The Host Identity Protocol
15
The responder must be able to respond to I1 packets without consuming much CPU power in order to prevent flooding attacks. However, the responder must sign the R1 packet with its private RSA key. The signature allows the initiator to verify that the R1 packet was generated by the legitimate responder. The creation of the Diffie Hellman key and the RSA signature process are CPU-intensive operations (see section 3.1.3 for details). These operations slow down the packet processes and generate load on the responder. The responder can pre-create the R1 packet including the signature and the DH public key in order to avoid CPU-demanding PK operations during the BEX. It stores the pre-created packet and uses it whenever an I1 packet arrives. The responder reuses the pre-created R1 packet for multiple HIP associations. Some parameter fields of the R1 packet are not covered by the RSA signature in order to support the pre-creation of R1 packets. Especially parameters which need to be distinct for each association, such as the puzzle values or the echo request, are added to the pre-created packet after the signature. The responder adds these parameters to the R1 packet right before it sends the packet to the initiator. The RSA signature provides no protection against replay attacks since it is generated for the pre-created R1 packet which may be used for several HIP associations. 2.1.4.4
R1 Processing
When the initiator receives R1 packets, it verifies the identifier of the responder by verifying the signature of the R1 packet. It also checks if the HI belongs to the HIT which was used in order to address the responder. As the HI of the responder is the public key of the signature, the R1 signature is verified by using its HI. The initiator uses a certain amount of CPU cycles to solve the puzzle. The details of the puzzle algorithm are explained in section 2.1.5.3. The initiator computes the Diffie Hellman shared secret with the peer’s Diffie Hellman public key and its own private DH key. It derives all necessary symmetric keys and secrets from this key material. These keys are used by IPsec and for authenticating the control packets of the HIP session with the Hashed Message Authentication Codes (HMAC) [BCK96]. The initiator selects its preferred cryptographic algorithms from the set of algorithms offered in the HIP transform parameter. The symmetric keys and the selected algorithms are used in order to set up an IPsec security context. The IPsec security policies and security associations for incoming packets are set up at this stage. 2.1.4.5
Second Initiator Packet
The second initiator packet (I2) contains the public key of the initiator for the DH key exchange. The initiator adds the puzzle solution to the I2 packet. It copies the echo request parameter from the R1 to the I2 packet as an echo response parameter. The initiator sends the SPI value which identifies the security association in an ESP info parameter. The responder needs this value to set up its outgoing IPsec SAs. The initiator selects one HIP transform suite from the HIP transform parameter in the R1 message and transmits its choice in a HIP transform parameter. The I2 packet is protected by an HMAC signature and an additional RSA signature. The RSA signature is generated with the private key which belongs to the HI of the initiator.
16
2. Background
The signature proves that the packet has been sent by the initiator. The HMAC signature protects the responder from DoS attacks with bogus DH keys. An attacker could generate bogus DH keys and bogus RSA signatures. The HMAC signature reveals bogus DH keys. The responder drops the packet before verifying the bogus RSA signature. The initiator is now in possession of the shared secret, which will be used for the HIP association. It has verified the identity of the responder and the authenticity of the R1 packet. It has established an incoming SA and waits for the second responder packet. 2.1.4.6
I2 Processing
The responder first checks the puzzle solution when it receives an I2 packet. Depending on the implementation, it may use the echo response or R1 generation counter parameter contained in the I2 packet to verify the validity and freshness of the puzzle. A valid puzzle indicates that the initiator has spent the required amount of CPU cycles to solve the puzzle. The responder does not process packets with invalid puzzle solutions. The responder calculates the shared Diffie Hellman secret and checks HMAC in the packet. It verifies the HI of the initiator by verifying the RSA signature. It derives the IPsec keys from the shared DH secret. The responder sets up its IPsec tunnel to the initiator with these keys and the algorithm selection in the transform parameter. 2.1.4.7
The Second Responder Packet
The responder sends back the second responder packet (R2). This packet contains the ESP info parameter that encodes the information necessary to set up the outgoing IPsec security associations at the initiator side. The packet is protected by an RSA signature which proves that the R2 packet was in fact generated by the responder. Moreover, the R2 packet is protected with an HMAC which is created with shared key, derived from the DH key exchange. This HMAC signature allows the initiator to verify the authenticity of the R2 packet in a computationally inexpensive way. 2.1.4.8
R2 Processing
The initiator first checks the HMAC signature of the packet. Only if it is valid, it continues to process the packet packet and checks the RSA signature of the R2 packet. The HMAC verification reveals faked packets and saves the host from performing expensive PK operations on bogus data. The initiator sets up its outgoing IPsec security associations according to the information received in the ESP info parameter. 2.1.4.9
Concluding the Base Exchange
The R2 packet concludes the base exchange. The HIP hosts have established the related HIP context and an IPsec tunnel. The shared keys for message authentication and payload encryption have been exchanged. The hosts can now begin to send payload like a TCP SYN or UDP packets in order to deliver application layer data. This payload is protected by IPsec.
2.1. The Host Identity Protocol
2.1.5
17
DoS Prevention
The HIP base exchange is resistant against certain kinds of denial of service attacks. The goal of a DoS attack is to consume resources of a victim to an extent that it is not able to provide adequate or any service to legitimate clients. DoS attacks often aim at mechanisms which establish state, use network bandwidth, require a large amount of memory, or perform CPU intensive computations. An attacker wastes resources of the responder by connecting multiple times until the resources which are used for the connection establishment are depleted. HIP introduces special DoS protection measures to protect responders. It delays the point when the responder has to establish state until the peer’s HI and IP address are verified. It also introduces a mechanism to slow I2 flooding attacks. 2.1.5.1
Delayed State Establishment
The BEX has been designed to delay the process of state establishment on the responder side as long as possible. The responder does not have to establish state before the I2 message is verified successfully. This delays the state establishment until the validity of the initiator’s IP address and its HI was verified. This prevents attacks with spoofed IP addresses because the attacker has to be able to receive R1 message and reply with an I2 message via the IP address. 2.1.5.2
The Echo Request Mechanism
An attacker could still use an R1 message and send valid I2 replies to this R1 with spoofed IP addresses. This potential DoS weakness is circumvented by using the echo request parameter. The echo request allows the responder to hide an obscured hint to the initiator’s IP addresses and its host ID in it. The encoding should be done in a secure way to ensure that the attacker can not forge echo replies. Hashing a secret and the initiator’s addresses with a cryptographic hash function provides such encoding. Encoding information about an association in an I2 echo request parameter enables the responder to check the validity of the I2 message in a very efficient way. The attacker, however, is unable to forge valid I2 packets with spoofed IP addresses because it is unable to generate valid echo responses since it does not know the responder’s secret. Moreover, the state establishment is delayed until the initiator has proven that it has solved the computational puzzle. 2.1.5.3
The Puzzle Mechanism
The responder can use the puzzle mechanism to generate CPU load on the initiator. The puzzle slows down an attacker who tries to establish numerous HIP associations at the same time. The puzzle gives the responder an advantage over the attacker as it is hard to compute but easy to verify. The responder can limit the frequency of valid I2 packets from an attacker by increasing the puzzle difficulty. An increased puzzle difficulty makes the puzzle harder to solve but does not increase the effort for the puzzle verification. The puzzle forces the initiator to apply a hash function repeatedly on the concatenation with I until the result fulfils a special property. The responder provides a random value I and the puzzle difficulty K. The initiator’s task is to find a number J which, concatenated with I and hashed with the selected cryptographic hash function, yields a result with a sequence of K zeros as lowest order bits.
18
2. Background
The initiator repeatedly varies J and hashes the result until it finds a suitable value for J. It returns J and I as puzzle solution. The responder checks the puzzle solution by applying the hash function to the concatenation of I and J. The solution is valid when the K lowest order bits of the result are zero. The puzzle protects the use of CPU intensive PK cryptography on the responder. Increased puzzle difficulties force the attacker to spend more CPU time on solving the puzzle. This slows down I2 floods from few attackers to a degree which the responder can handle. Initiators with little CPU power, such as mobile devices, suffer from difficult puzzles as well. These clients may not be able to solve the puzzle within an acceptable time. Nevertheless, the use of costly PK cryptography requires DoS countermeasures to avoid simple and efficient DoS attacks on HIP hosts. The responder can set the puzzle difficulty to zero while it is not under attack. This relieves the initiator from solving the puzzle.
2.1.6
HIP Control Channel
Unlike payload, HIP handles control messages directly. IPsec only takes care of the payload. HIP uses control messages to establish, update, and close a HIP association. These messages are protected by signatures to prevent attacks but they are unencrypted to allow middleboxes to inspect them and to learn about HIP associations. 2.1.6.1
Packet Format
All HIP control messages share a common basic structure. Figure 2.5 shows the HIP header. The type of the HIP header determines how HIP processes the packet. We use capitalized letters to indicate the type of a message or packet. The message type specifies whether HIP uses the packet during the BEX or whether the packet is an UPDATE or CLOSE packet. Each HIP control packet contains several fields which provide information about the protocol version, the length of the packet and the checksum of the header. The next header field could be used to attach more protocol headers to HIP control packets. Currently, transport of further headers is not supported by the HIP protocol. The header also contains the HITs of both communicating peers. These are used in order to identify the right HIP context on the remote host. 2.1.6.2
Parameter Format
Several HIP parameters can be attached to the HIP header. The HIP parameters carry all the information which is necessary in order to establish, modify or close a HIP association. The parameters contain values like the Diffie Hellman keys, the host identifiers, sequence numbers, or signatures. All HIP parameters have the same basic structure: Type Length Value (TLV). They consist of a type field and a field which indicates the length of the parameter. A variable data field follows these two fields. It contains the value of the parameter. The type field tells HIP how to interpret the variable data field. The Diffie Hellman parameter, depicted in 2.5, for example, carries the type number 513. Therefore, HIP interprets the content of the value field as group identifier, key length, and public key. Other parameters have different structures for the variable data block. Padding is applied in order to align the parameters in the HIP header.
2.1. The Host Identity Protocol
19
Figure 2.5: The structure of HIP control packets and HIP parameters. The Diffie Hellman parameter is depicted as an example. The lowest order bit of the type field is called the critical bit. It indicates whether a parameter is critical for the processing of the HIP control message. A HIP implementation must understand all critical parameters contained in a message. It must drop the entire packet if it encounters a packet which contains an unknown parameter with the critical bit set. The critical bit is part of the parameter number. Therefore, parameter types with even numbers are non-critical while odd parameter type numbers are critical. The Diffie Hellman parameter, for example, has the parameter type number 513. Since the lowest order bit in the binary representation of 513 is 1, it is critical. The HIP header may contain any number of HIP parameters as long as the length of all parameters does not exceed the maximum parameter field length of 2008 bytes. The
Figure 2.6: HIP parameters are classified by their type numbers. Certain ranges of type numbers have similar functionalities and security requirements.
20
2. Background
parameters must be attached in strictly ascending order of their parameter type numbers. This ensures that the right parameters are protected by signatures. The possible range for parameter type numbers is 0 to 65535 (216 − 1). The HIP base draft defines several sub-ranges for type numbers. All parameters in a sub-range have similar functions. E.g. parameters with type numbers from 1 to 1023 are used during the base exchange and during updates and are covered by signatures. The range from 61440 to 62463 is reserved for signatures. This means that signatures are applied after all necessary parameters with type numbers lower than 61440 have been added to the HIP control packet. This ensures that all these values are signed whenever a signature is applied. Figure 2.6 shows the type number range and how it is divided into subranges. Packets with parameter types which are not in strict ascending orders are considered to be malformed and are discarded. Several number ranges have been reserved for future protocol extensions. The HIP base draft and the extension drafts provide a full description of all parameters.
2.1.7
HIP and Middleboxes
The new namespace and the way HIP hosts interact cause new problems with middleboxes. NAT boxes or firewalls, for example, prohibit incoming traffic from unknown IP addresses. Exactly this happens when a host changes its location. It sends traffic from an address it has not used previously. A NATed host will not receive the update messages of the mobile peer because incoming traffic from unknown IP addresses is discarded by the NAT box. Another problem arises because HIP control messages and IPsec traffic do not contain socket identifiers which are needed for multiplexing and demultiplexing purposes on NAT devices which perform Network Address and Port Translation (NAPT). HIP and IPsec define an UDP-based fallback format [HSV+ 05] for these cases. HIP was designed to be middlebox friendly. It provides additional mechanisms to mitigate these problems with future generations of packet-inspecting middleboxes. HIP-aware middleboxes can read important information from the BEX packet. This enables them to authenticate the traffic as well as the identities of two communicating peers. SPI-aware NATs, like those described in [YN04] for example, can gather information about the SPIs which will be used by IPsec. Middleboxes can use this information to multiplex and demultiplex the IPsec traffic. All HIP control packets are unencrypted and contain PK signatures in order to support middleboxes.
2.1.8
Mobility
The set of IP addresses assigned to a host, changes every time the host changes its point of network attachment or when it turns on or off a network device. An established HIP association has to be updated in order to keep the mapping from HIs to IP addresses. The communicating peers exchange these updates directly. Third parties are only involved in special cases. A mobile host initiates the update process to inform its stationary peer whenever its set of IP addresses changes. Both hosts update their HIP state, modify their IPsec security associations, if necessary, and continue to communicate. The general case of the HIP update process is defined in the HIP mobility and multihoming draft [Hen06].
2.1. The Host Identity Protocol
21
Figure 2.7: The update process. A mobile host informs its stationary peer about its new IP address. The update procedure handles both, mobility and multihoming. A host defines a preferred locator for a HIP association whenever it is capable to use several IP addresses simultaneously. It sends and expects HIP control packets and ESP payload on this locator while the other IP addresses serve as fallback or may be used for other HIP associations. The update process usually consists of three HIP control packets. We illustrate the update process with a simple mobility event in which a mobile host changes from one subnetwork to another. The mobile host is not multihomed in this example. Figure 2.7 depicts the update process. The First Update Packet Both hosts must have completed the base exchange and have successfully established a HIP association before the mobile host moves. The mobile host is disconnected from all networks for a short period of time while it switches from one subnetwork to the other3 . A new IP address, which matches the address prefix of the new subnetwork, is assigned to the network interface of the mobile host during the handover process. The mobile host does typically not know this IP address before it moves. Therefore, both hosts can not agree on the new IP address before the mobility event occurs. The mobile host initiates the update process as soon as it is connected to the new subnetwork. It sends a HIP UPDATE packet containing the new set of IP addresses, the ESP security parameter index, and a sequence number to prevent replay attacks to its stationary peer. The stationary host does not need the SPI value in this simple case of mobility as it remains constant. It is attached to the packet, nevertheless, to support packet-inspecting middleboxes in learning about the new IP address which will be used for the ESP tunnel associated with the SPI. The SPI value is needed by the HIP peers in case a host decides to rekey and, therefore, uses a new IPsec association. The packet is protected by an HMAC signature and signed with the private key of the host. The stationary is not required to verify the PK signatures as it is in possession of the shared 3 HIP also supports soft handovers in which the hosts are connected to both networks during the mobility update.
22
2. Background
secret for the HMAC verification, which causes less computational overhead. Middleboxes, however, can not use this way of authentication because they are not in possession of the shared key. They use the PK signatures to authenticate the packets. For some classes of middleboxes, it is important to learn about the new IP addresses. NATs, for example, typically only allow traffic between hosts when the transfer was initiated by a host behind the NAT. Packets from all other IP addresses are usually blocked because no mapping between this IP address and a NATed host exists. This behavior causes problems whenever a mobile host communicates with a host behind a NAT box. The mobile host sends its HIP UPDATE packet from a new IP. The NAT middlebox will typically drop the UPDATE packets from this unknown IP address. HIP-aware middleboxes can use the PK signatures provided in the UPDATE packets to verify the HI of the mobile host. Thus, NAT mappings can be bound to HIs and SPIs instead of IP addresses which relaxes the problem stated above. The NAT can learn the new IP address of the mobile host from the UPDATE packet and forward it to the stationary host, though the packet was originated by an unknown IP address. The Second Update Packet First, the stationary peer verifies the HIP UPDATE packet from the mobile host. Then, it changes its HIT to IP mapping and updates its incoming and outgoing IPsec security associations. It sends back an UPDATE message which contains the SPI belonging to its incoming security association. It also appends an ACK parameter which acknowledges the previous UPDATE message, a sequence number as replay protection, and an echo request parameter. Again, the SPI is only needed by packet-inspecting middleboxes. The echo request is used as routability test. The mobile host must send the exact contents of the echo request parameter back to the stationary host to indicate that it is able to send and receive packets, using the new IP address. The Third Update Packet A third packet concludes the update process. It is sent by the mobile host and contains an ACK parameter which acknowledges the receipt of the second UPDATE packet. It furthermore contains the response to the echo request in an echo response parameter. Like its succeeding packets, the third UPDATE packet is signed with HMAC and RSA.
2.1.9
The Double Jump Problem
HIP hosts can use a decentralized update process as long as one of the hosts stays stationary during the update process. This can be considered the most common case. However, decentralized updates can not handle the case in which both hosts move at the same time. In this case neither host is able to reach its peer because both hosts use obsolete IP addresses to address. The HIP name resolution infrastructure provides a way to resolve the HIT of the peer to its new IP. This requires that the hosts keep their entries in the name resolution infrastructure upto-date. Furthermore, distributed name resolution services must be able to handle and distribute updates rapidly.
2.2. Cryptography
2.1.10
23
Closing a HIP Association
Hosts may close a HIP association when it is not needed anymore. The hosts can stop maintaining the association and free the resources which are consumed by the HIP and IPsec state. HIP defines the control packet type CLOSE for this purpose. Close messages include an echo request which is copied to the CLOSE ACK message by the responder. The CLOSE message is signed with an HMAC and RSA. The HMAC protects the close process from replay attacks while the RSA signature enables middleboxes to verify the CLOSE message. A host that receives a valid CLOSE message replies with its own CLOSE message, containing an ACK parameter and the echo response parameter. The message is also signed with an HMAC and an RSA signature. A host that receives a CLOSE ACK messages checks the HMAC, the signature, and the echo response contained in the packet to verify that the CLOSE ACK is a response to a CLOSE message set by itself. It closes the association and deletes the HIP state.
2.2
Cryptography
HIP uses a variety of different mechanisms to ensure confidentiality, authenticity and integrity of HIP control messages and payload. The mechanisms used in this work can be categorized into three classes of algorithms and cryptographic techniques: Symmetric cryptography, public-key cryptography and the use of One-Way Hash Functions. These techniques complement each other. The combination of all of these techniques provides the basis for secure communication and decentralized end-host mobility.
2.2.1
Symmetric Cryptography
Algorithms which are categorized as symmetric cryptography typically use identical keys, or keys which are trivially related, for encryption and decryption. If they are not the same, one key can be generated from the other. This property requires the communicating entities to keep secret in order to prevent third parties from decrypting encrypted data. Hosts can use symmetric key cryptography in order to secure a communication channel. Both hosts must be in possession of the symmetric key. Popular symmetric cryptography algorithms are the Advanced Encryption Standard (AES) [Sta01], the Digital Encryption Standard (DES) [FIP99], triple DES (3DES), and Blowfish [Sch93]. HIP uses symmetric cryptography indirectly by utilizing IPsec. The ESP protocol is able to use different symmetric ciphers to protect the payload. The question how to exchange the symmetric keys arises whenever two host employ symmetric cryptography. HIP hosts utilize public-key cryptography to securely agree on shared secrets. The Diffie Hellman key exchange generates the necessary symmetric keys during the base exchange.
2.2.2
Public-Key Cryptography
Unlike symmetric key cryptography, public-key cryptography uses encryption and decryption keys which are related in a non-trivial way. One of these keys is published while the other key is kept private. It is computationally infeasible to generate the private key from the public key. Typically, the public key is used for encryption while the private key is used for decryption. This enables hosts to send encrypted data to any host without exchanging shared secrets first, provided the sender knows the public key of the receiver.
24
2. Background
Easy, Hard, Feasible and Infeasible Public-key encryption algorithms are based on so-called trapdoor functions. These trapdoor functions can be calculated easily but are hard to reverse without additional information in form of a private keys. In this context, the terms hard and easy, as well as feasible and infeasible relate to the complexity of the calculation. Computations which take dozens of years up to millions of years are denoted hard or infeasible. On the contrary, computations which can be calculated in a matter of milliseconds or seconds, depending on the computational power which is used, are denoted easy or feasible. Public-key cryptography is based on mathematical problems that are hard to solve. Prime factorization and the discrete logarithm problem are such problems. HIP uses PK cryptography to authenticate hosts. The HIs are essentially public keys. Furthermore, HIP generates the keys for the symmetric encryption by utilizing PK cryptography in the Diffie Hellman key exchange. 2.2.2.1
Diffie Hellman Key Exchange
The first PK cryptosystem was published by Whitfield Diffie and Martin Hellman in 1976 [DH76]. It provides a way to securely exchange symmetric keys over insecure channels. It is based on the discrete logarithm problem. The original version uses the multiplicative group of integers modulo p. Two parties that want to exchange a secret key agree on a large prime number p and a primitive g modulo p. Both numbers g and p may be exchanged in public. In practice, only few combinations of g and p are in use. These Diffie Hellman groups do not need to be kept secret. They are publicly defined in protocol specifications as for the Internet Key Exchange protocol (IKE) [HC98, KK03]. The Key Exchange The DH key exchange consists of four steps. A key is publicly negotiated during these steps. However, an attacker can not create the shared secret due to the computational complexity of the discrete logarithm problem. We give a short description of the four steps. Further explanations and analysis are provided in [Wät04] 1. The initiator (I) of the key exchange selects a random number xI ∈ {1, . . . , p − 2} and calculates yI = g xI modp. It sends yI to the responder R and keeps xI secret. It is computationally infeasible to calculate xI from g xI due to the complexity of the discrete logarithm problem. 2. The responder (R) randomly selects a secret number xR ∈ {1, . . . , p − 2}. It calculates yR = g xR mod p and s = yIxR mod p = g xI xR mod p. The result s is the shared secret. It sends back yR to the initiator. The responder may destroy xI afterwards. 3. The initiator calculates the shared secret s = yRxI modp = g xR xI modp = g xR xI modp. It may discard xI now. Both hosts are in possession of the secret key s after the key exchange. They generate symmetric keys of the desired key length from this secret by selecting some bits or combinations of bits from this key. Typical key lengths l, which are assumed to be safe for longer terms, are 1024 bits or more. The values p, g, xI , xR , and s are all large numbers
2.2. Cryptography
25
of length l. Arithmetic computations on large numbers are typically not supported in hardware. Especially the exponentiation of large numbers is costly in terms of CPU cycles. The Diffie Hellman key exchange offers perfect forward secrecy provided both communicating peers destroy the shared key s, xI , xR , and the symmetric keys they have generated from the secret. The values g xI mod p and g xR mod p can be pre-calculated which reduces the computational overhead of the DH key exchange. The responder pre-calculates g xR mod p in the precreated R1 packet. The initiator can store different g xI mod p in a key pool. These pre-calculations can be done whenever the host is idle. The only computation which is necessary during the BEX is to generate g xI xR mod p on both sides. 2.2.2.2
The RSA Algorithm
The RSA algorithm is another PK encryption algorithm. Rivest, Shamir, and Adelman published in 1978 [RSA77]. The RSA algorithm is named after their initials. It is the first PK algorithm that was suitable for encryption as well as for message authentication. The RSA algorithm builds on the fact that though multiplying two large prime numbers is easy, factorizing the product into the two prime factors is computationally hard. The prime factorization problem is used as a trapdoor function which enables encryption and decryption with a public-key pair. Assume that a sender (S) wants to send an encrypted message m to a receiver (R) over an insecure channel. The receiver first generates a public-key pair and publishes its public key kpub . The sender uses this public key to encrypt the message with the RSA encryption function E and sends the encrypted message Ekpub (m) to R. R can use its private key kpriv and the decryption function D to decrypt the message Dkpriv (Ekpub (m)) = m. RSA Key Generation The RSA key generation process is used to find a public key and a private key that can be used for encryption and decryption, respectively. The key generation process consists of four steps. Mathematic preliminaries and a detailed description are provided by Wätjen [Wät04].
1. Find two large prime numbers p and q of similar size. 2. Calculate n = pq and ϕ(n) = (p − 1)(q − 1). ϕ is Euler’s ϕ function which gives the amount of numbers x with x < n and gcd(x, n) = 1 see Wätjens explanations for details. gcd(x, y) denotes the Greatest Common Divisor of x and y. 3. Choose a random number e, 1 < e < ϕ(n) with gcd(e, ϕ(n)) = 1. 4. Calculate d = e−1 mod ϕ(n) by using the extended Euclidean algorithm
The pair (n, e) is used as public key kpub and d is used as private key kpriv .
26
2. Background
RSA Encryption and Decryption A sender encrypts the message by using the public key of the receiver to send an encrypted message. The encryption process can be summarized in three steps: 1. S looks up the public key of R kpub = (n, e). This can be done by using some public-key infrastructure or by asking R for its public key. 2. S divides the message into pieces and transforms them into a number m ∈ Zn . 3. S calculates the cipher text c = me mod n. S can send the cipher text c to R over an insecure channel as only R is able to decrypt c by using its private key kpub The decryption process repeats the encryption process with d used instead of e. cd mod n = (me mod n)d mod n = m
(2.1)
Proofs and further explanations are provided in [Wät04], page 71 and following. The RSA signatures are considered to be secure provided that suitable numbers for n = qp are used4 and that advances in cryptography do not yield algorithms which are able to efficiently calculate prime factors or to solve other equivalent problems. Typical sizes for n, q, p, d, and e are 1024 bits and more. Typically, small numbers are chosen for e which makes encryption more efficient than decryption because d depends on the choice of e and d can not be chosen freely. RSA Signatures The RSA encryption and decryption process can be used in order to digitally sign messages. A valid signature ensures that the content of a message has not been modified or forged by third parties which do not in possession of the private key components. The signature process works similar to the encryption process. The only difference is that the encryption is performed with the private key of the sender. The message can be decrypted with the public key of the sender. The encryption process with the private key is called signature process while the decryption is the signature verification. Like the DH key exchange, RSA encryption and decryption require to compute CPUintensive exponentiation of large numbers which slows down the encryption and decryption process. Therefore, RSA is mainly used to transmit encrypted symmetric keys and to sign short message digests (see section 2.2.3). HIP ties the identity of a host to an RSA key pair. Thus, not only the authenticity and integrity of messages can be checked but also the identity of their originator. DSA Signatures The Digital Signature Algorithm (DSA) has been specified to be used with the Digital Signature Standard (DSS). It is a variety of the El Gamal signature scheme and requires the use of a cryptographic hash function. Like the Diffie Hellman key exchange, DSA relies on the complexity of the discrete logarithm problem. The properties and the performance of DSA are similar to the ones of RSA. A detailed description is provided in the DSA standard documents and Wätjen, pages 114 and following [Wät04]. 4
The selection and the size of the numbers matter. For details see [Wät04], pages 78 and following.
2.2. Cryptography
2.2.3
27
One-Way Cryptographic Hash Functions
One-way cryptographic hash functions are a third class of cryptographic mechanisms. These functions transform a given value of variable length into a value of length n. The computation of H(x) should be feasible, while reversing the function should be infeasible. Cryptographic hash functions should be: Second preimage resistant A hash function is second preimage resistant if for a given x it is computationally hard to find x0 6= x with H(x0 ) = H(x) Collision resistant A hash function is collision resistant if it computationally hard to find any two values x and x0 with x 6= x0 and H(x) = H(x0 ) Preimage resistant A hash function is called preimage resistant if for a given z = H(x) it is computationally hard to find a preimage x0 with H(x0 ) = z No correlation between the input and the output of a cryptographic hash function should be perceptible. Moreover, results of the function should be distributed equally over the image of H. There are two ways of designing hash functions. Collision resistant hash functions can be based on the same algebraic problems as public-key cryptosystems. These hash functions have the same computational complexity but also the same performance issues. Alternatively, block-cipher-based hash functions, following the Merkle-Damgård construction [Mer89, Dam90], are cheap in terms of CPU cycles. They can be applied even on computers with low processing power. The Merkle-Damgård construction is the most common design for cryptographic hash functions. It constructs hash functions with arbitrary input length by cascading a compression function. Since the computational complexity of these hash functions is very low compared to the complexity of public-key operations, they are widely deployed and used for many purposes. Examples for popular cryptographic hash functions are the SHA hash function family [Nat95] and MD5 [Riv92]. In practice, cryptographic hash functions are often used for message authentication. They reduce the size of messages which are about to be signed to a fixed short length, the message digest. Signing long messages with RSA or DSA is a CPU intensive operation. To avoid this, the fixed length message digest is signed instead. This reduces the length of the data to be signed while keeping the properties of the signature. It is computationally infeasible to find another message which can be used with the signed hash because of the collision resistance and second preimage resistance properties. HIP control messages are hashed and the RSA signatures are applied to the message digest. 2.2.3.1
Hashed Message Authentication Codes: HMACs
Cryptographic hash functions provide one possible method to verify the authenticity and the origin of a message. In order to sign messages with hash functions, all communication peers must be in possession of a shared secret. Given the shared secret s, a message m, and a cryptographic hash function H(x), the peers compute a Message Authentication Code, (MAC) M AC(x), in order to sign a message. The symbol k denotes concatenation in this context.
28
2. Background
M AC(m) = H(k k m) This simple scheme allows hosts which possess the secret key to authenticate the message m by calculating it, using the secret key. Other hosts are not able to forge this signature as they are not in possession of the secret key. The preimage resistance of the cryptographic hash function prevents the secret k from being calculated from M AC(m) and the property of collision resistance prevents an m0 with h(m0 ) = h(k k m) from being found. However, this is only true when an ideal hash function is used. Using practical hash functions leads to security problems. Iterative hash functions which are designed according to the Merkle-Damgård construction principles are susceptible to length extension attacks which cause serious problems with this naive MAC. An attacker can forge the MAC for a suitable m. Mironov describes this attack and further security issues for practical hash functions [Mir05]. Descriptions and practical implications of further attacks on hash functions were provided by Wang [WY05], Joux [Jou04], Kaminsky [Kam04], and others. The HMAC message authentication mechanism has been designed to provide a safe way to authenticate messages. It has been standardized by the IETF in RFC 2104 [KBC97]. The HMAC is calculated with the following formula:
HM ACk (m) = H (k ⊕ opad) k H (k ⊕ ipad) k m
! .
The constants opad = 0x5c5c5c..5c and ipad = 0x3c3c3c..3c of the same size as the input block length of the hash function (512 bit for SHA-1 and MD5). Ipad and opad in ipad and opad are mnemonics for inner and outer padding. The symbol ⊕ denotes exclusive or. The HMAC computation performs three steps. It concatenates a secret key with the message. It adds noise to the key to complicate attacks on the mechanism and uses two hash operations to generate the keyed-hash message authentication code. Signature verification is analogous to the signature generation process. Only messages exchanged between hosts which share a secret key can be authenticated. Therefore, other measures are needed to identify an unknown host. HIP, for example, uses the authenticated Diffie Hellman key exchange to exchange the shared key and to verify the identities of hosts. The HMAC verification is very cheap in terms of CPU cycles. It only requires two hash computations and, therefore, outperforms signature schemes which are based on public-key algorithms by magnitudes. 2.2.3.2
Hash Chains
In 1981, Leslie Lamport proposed to use chains of hashes to protect remote password authentication over insecure channels from replay and eavesdropping [Lam81]. Since then, hash chains have been used in several other fields of application like electronic cash [STS], micropayments [RS96], and wormhole detection in mobile ad-hoc networks [HPJ01]. The basic idea behind hash chains is the iterated application of a cryptographic hash function on some random or pseudo random seed value r, which we call seed of the hash
2.2. Cryptography
29
chain. The hash function H is applied to this initial value. The result of the hash function is used as input for the next round until the hash chain has reached the desired length. The intermediate results form a chain of hashes which is called the hash chain.
h0 = r hn = H(hn−1 ) ∀ n ∈ N+ = H(H(H(· · · H(r) · · · ))) n times
(2.2) (2.3) (2.4)
The sequence (hi , hi−1 , hi−2 , . . . , h1 , r) is called the hash chain. Its first element hi is called the hash chain anchor. In order to use a hash chain, the anchor is published while the rest of the chain is kept secret. The elements of the hash chain are disclosed in reverse order of their generation beginning with the anchor value. Thus, the first element which is revealed is hi , the second one is hi−1 , and so on. Used in this way, hash chains provide a number of appealing properties which allow the use for authentication in several ways. • Given hi−1 and hi , it is easy to verify that hi belongs to the same hash chain as hi−1 . This property results from the equation 2.3 and the basic requirement for hash functions, that it should be feasible to calculate a hash function. • It is computationally hard to find hi−1 if only hi is given. This property is provided by the preimage resistance of the hash function. It ensures that someone who is not in possession of the hash chain can not calculate unrevealed elements from already disclosed ones. • Given hi+1 , it is hard to find an h0 with H(h0 ) = H(hi ) = hi+1 . This property also arises from the preimage resistance of the hash function. It ensures that no one can forge a single unrevealed element of the hash chain. • Given hi , it is possible to verify that hi−n is part of the same hash chain if 0 < n ≤ i. This property comes from the iterated construction of the hash function. The check requires iterated application of the hash function to hi . It ensures that hash chain values can be verified even when some values get lost due to transmission errors or attacks. The owner of a hash chain can exchange an anchor with its peer. It can disclose the next undisclosed hash chain element later. The peer can verify that the owner of the hash chain has disclosed this element. There are three approaches for signing messages with hash chains. One-time signaturebased approaches, time-based approaches, and interaction-based approaches. The next sections give a short overview of these techniques and their properties.
2.2.4
One-time Signatures
Lamport proposed one-time signatures based on hash functions. A host uses two random values r and r0 and applies the hash function H to both. The results H(r) and H(r0 ) are published as public key. A one bit message can be signed by publishing r as signature s if the bit is 1 and r0 otherwise.
30
2. Background
Comparing the hash of the signature H(s) with the public key values H(r) and H(r0 ) verifies or falsifies the signature of the message. This signature can be used to sign l-bit messages by using 2l hashes. The signature allows instant verification, provided the public key is known. However, 2l hashes must be calculated per signature. Merkle [Mer88] improves this scheme and reduces the number of hashes to l +blog2 (l)c+1 and the average number of hashes per signature to l+blog22 (l)c+1 . This is achieved by only signing the bits with value 1. The number of 1 bits is appended to the message and signed as well to prevent signature forgery. This improves the efficiency almost by a factor of two. Winternitz proposed a scheme which reduces the signature size even further but his approach requires more computation. The scheme uses two hash chains of length l to sign a log2 (l) bit long message. Only two hashes need to be transmitted to sign a message but a multitude of hashes must be computed in order to generate the public keys. Zhang [Zha98] proposes two protocols for signing routing messages. These protocols use hash chains to provide the hashes for the signature. This enables the use of one public key which consists of a set of hash chain anchors to sign several messages. The signature size for these protocols is about 2 to 4KB per signature and has the same computational overhead as Merkle’s scheme.
2.2.5
Time-Based Signatures
The Timed Efficient Stream Loss-tolerant Authentication (TESLA) [PSC+ 05, PCTS02] protocol uses a time-based approach to sign messages. The approach requires loose time synchronization between the communicating peers. The sender sends a hash anchor to a group of receivers. Each message is protected by an HMAC which is created with an unrevealed element of the hash chain. The sender uses each unrevealed element of the hash chain to sign messages for a certain time span. The element is disclosed after this time span. Receivers can authenticate the messages as soon as the corresponding element is disclosed. Messages which were signed with an element that has already been disclosed are dropped by the receiver to prevent attacks. The time synchronization ensures that receivers only accept packets while the sender has not disclosed the corresponding hash chain element. This ensures that only the sender, who is in possession of the hash chain, can sign messages. An attacker can only sign packets after the disclosure of the element. At that time, other hosts will not accept any more packets signed with the hash chain element. When disclosing an element, the next unrevealed element of the hash chain becomes the element with which future packets are signed. Again, it is only valid for a certain fixed interval before it is disclosed. Using a time-based instead of a message-based authentication method enables TESLA to deliver authenticated messages with little additional overhead. Signing messages requires the use of one hash chain element per time interval and the usual cost for generating and verifying an HMAC. TESLA introduces an additional delay. A receiver can not verify the message before the sender discloses the corresponding hash chain element. The receiver has to buffer the messages until then.
2.2. Cryptography
31
Figure 2.8: Signatures with the TESLA protocol. The sender signs and sends multiple messages. The receiver verifies the messages after the sender has disclosed hi . Another disadvantage is that hash elements are revealed even when no signed payload was sent during the last time interval. Figure 2.8 illustrates the message flow. The sender uses hi to generate the HMAC of the messages. The receiver accepts and buffers all packets while hi is valid. It drops messages signed with hi if they arrive in the next time period. This happens to message4 in the figure. The receiver can start to verify the buffered messages after receiving the disclosed element of the hash chain hi .
2.2.6
Interactive Signatures Based on Hash Chains
Torvinen and Ylitalo [TY04] use an approach which is similar to TESLA to sign messages with hash chains and hash functions. Undisclosed messages are used in order to generate message authentication codes. The receiver can verify the messages after the sender has disclosed the hash chain element. Like in TESLA, a mechanism is required to separate the time span in which a hash chain element is used for signing messages from the time when it is used for message verification. TESLA uses loose time synchronization while the interactive approach relies on interaction between the communicating peers. Figure 2.9 illustrates the signature process. The sender sends a message and an HMAC generated with an unrevealed hash chain element to the receiver. The receiver acknowledges the receipt of the message and buffers the message. The sender discloses the corresponding
32
2. Background
Figure 2.9: Interactive hash chain signature. The Sender signs and sends a message. The receiver acknowledges the receipt. The sender discloses the secret hash chain element. hash chain element. Like in TESLA, the receiver can verify the buffered message as soon as it receives the disclosed hash chain element. The protocol must fulfil two basic requirements in order to be safe. 1. The receiver must receive the message, which has been signed with a hash chain element hi , before the sender discloses hi . 2. The receiver must not accept any messages signed with hi after the sender has disclosed hi . Requirement number one ensures that only the host, which possesses a hash chain, can sign messages. An attacker can not sign messages with the sender’s hash chain as it is not in possession of the required hash chain element. The sender does not disclose its next hash chain element before it has received the signed packet. It waits for the acknowledgement from the receiver before it sends the next hash chain element. Requirement number one demands that the sender can distinguish valid acknowledgements from acknowledgements an attacker may have forged. Requirement number two ensures that an attacker can not sign any messages with a disclosed element of a hash chain. The receiver will not accept any packets after it has received the signature from the sender. Providing this property demands that the receiver must be able to distinguish signature packets from bogus packets which an attacker could send to disturb the communication. Otherwise, an attacker could constantly send forged packets to force the receiver to deny valid signature packets. The interactive approach utilizes hash chains to meet these requirements. Not only the sender but also the receiver uses a hash chain. Every packet contains a hash chain element as clear text. This element ensures that the packet was sent by the legitimate sender. The receiver verifies that the message was sent by the legitimate sender. The receiver can verify this by hashing the contained cleartext hash value and comparing it to the last hash value revealed by the peer. This check indicates that the sender has sent some message but
2.3. Weak Authentication Techniques
33
it can not verify the message contents. Receiving the sender’s hash chain element signals the receiver that it may not accept any more packets containing this hash chain element. This guarantees property two. The receiver adds an element of its own hash chain to the acknowledgement message. This hash chain element provides the sender with the knowledge that the receiver has received the signed message. At this point, it is safe to disclose the next hash chain element which enables the receiver to verify the message. An attacker can not forge any packets without interaction with the legitimate hosts as it can not calculate undisclosed elements of the hosts hash chains. Even a man-in-the-middle attack can be prevented as an attacker can not sign messages before the sender has disclosed the next hash chain element and it will not disclose this element before the receiver has acknowledged the receipt of the signed packet. This acknowledgement can not be forged by an attacker because it contains an formerly undisclosed hash chain element. Two hash chains are an unforgeable chain of triggers with each element of the one chain triggering an element of the other chain to be published. The cleartext hash chain elements in the packets will, therefore, be called trigger values in this work. Interactive hash chain signatures do not require loose time synchronization nor do they introduce a fixed delay until the receiver can verify the packets. A delay of one additional Round-Trip-Time RTT is induced for every signed packet. The approach has more overhead than TESLA due to the additional interaction. However, the packets containing only trigger values are very small and require a negligible amount of network bandwidth. 2.2.6.1
Mobility and Multihoming Based on Hash Chain Signatures
Ylitalo and Torvinen have proposed the Weak Identifier Multihoming Protocol (WIMP) [YTN04]. WIMP establishes and maintains a communication context on remote peers. Their protocol provides end-host mobility and multihoming support. WIMP uses interactive hash chain signatures in order to secure the connection establishment and the update process. WIMP uses location-independent identifiers. These identifiers are translated to IP addresses above the network and below the transport layer. Like HIP, WIMP uses a four-way handshake. During this handshake, every host transmits one hash chain anchor to its peer. Wimp uses a technique called chained bootstrapping in order to secure the handshake process. The first two messages of the handshake are signed with the anchor values, which are revealed in the third and fourth message. Hosts can verify if the third or fourth message, respectively, have been sent by the same hosts as the first and the second message. WIMP uses secret-splitting in order to protect the update messages. A sender sends a signed message with its new set of IP addresses to the receiver. The receiver splits its hash chain element into pieces and sends it to the sender. It creates one piece for every network address of the sender. The sender waits for all pieces to arrive and replies with an acknowledgement and its next hash chain element. Splitting the hash chain element ensures that all addresses of the sender are routable and that these addresses belong to the sender.
2.3
Weak Authentication Techniques
Arkko and Nikander [AN02] compare different weak authentication techniques. Weak authentication relates to peers which use strong authentication techniques without trusted
34
2. Background
third parties. This authentication is called weak because a small possibility of an attack remains. Weak authentication is used when the costs for using strong authentication with third parties like PKIs surpass the benefits, for instance, if cheap lightweight devices get big and expensive in order to support strong authentication. Arkko and Nikander identify three classes of weak authentication techniques: Temporal separation describes the ability of hosts to relate communication at a certain time t1 to an earlier communication at time t0 . This means that a host can verify that the host it is talking to at t1 is the same host it has been talking to at t0 . This means that no one is able to impersonate the peer for a certain time span after t0 . Temporal separation can typically only be guaranteed under certain circumstances. For instance, the first contact at t0 must be authentic. There must not be an attacker on the communication path during this contact. Spatial Separation refers to the ability of a host to ensure that its peer is located on a certain communication path. In practice, this often means that the host is located at a certain network address. This property is often verified with challenge response mechanisms. For instance, the HIP echo request - echo response test ensures that a host is located at a certain IP address. However, hosts in a similar location might be able to pass the test if they are able to eavesdrop on traffic to a certain IP address and if they are able to spoof packets from this IP address. Asymmetric costs refer to the case in which the costs of an attack surpass the benefits for the attacker. This can be achieved by making it harder for the attacker to find the right target. This forces the attacker to perform multiple attacks which increases the costs for an attack. Arkko and Nikkander argue that sometimes insecure security is enough for the task at hand. They state that weak authentication is not suitable for applications which require real-world identities. However, it is more suitable for applications which do not have a demand for a real-world identity. Multi-homing, routing, and mobility are given as typical examples for such applications. An ephemeral identity is sufficient for these applications. Real-world identities which are ensured by a third party are, in most cases, too much overhead for these applications.
3. Problem Analysis HIP uses several cryptographic algorithms and protocols in order to provide secure communication and tamper-proof protocol functionality. Some of these technologies involve CPU-intensive calculations. Especially PK algorithms are known to be costly in terms of CPU cycles. In this chapter, we present our performance analysis of cryptographic functions used in HIP. We state the need for a lightweight version of HIP for CPU poor devices and we define the scope of lightweight HIP. We analyze how the cryptographic components of HIP interact and discuss the simplest solutions for a lightweight HIP.
3.1
Performance Analysis
HIP hosts build their communication context during the base exchange. The BEX requires both hosts to compute a number of different cryptographic algorithms. Both hosts perform a DH key exchange, sign and verify packets with RSA, and calculate HMAC signatures. The update process also requires the computation of RSA or DSA signatures in order to sign the HIP control packets. The public-key operations are known to be expensive in terms of CPU cycles. We estimate the impact of these PK operations on the performance of HIP by measuring the processing time for DH, RSA and DSA for different key lengths. We use this estimation to show that HIP considerably slows down the connection establishment and the update process on devices with low computational power.
3.1.1
Test Platform
We performed our measurements on two different platforms: a network server and a mobile device. Both run the Linux operating system and use the same measurement software. We have chosen these devices to allow comparisons of the performance of HIP on a fast system and a mobile device with low processing power. Network Server Our first test system is a network server equipped with a 3.2 GHz Intel Xeon processor with 1024 KB L1 cache. The CPU supports hyperthreading but we did not use multithreaded performance tests. The Xeon computer uses the Linux kernel version 2.6.16 which was patched for use with HIP.
36
3. Problem Analysis
Mobile Device Our mobile system is a Nokia 770 Internet Tablet (N770). It is equipped with a 220 MHz ARM-926 processor. For our measurements, we used the IT 2005 operating system, which is based on Linux. A custom-made Linux kernel of version 2.6.12.3 which was also patched for the use with HIP runs on the N770. The N770 Internet Tablet was designed for mobile communication, such as wireless web browsing and audio streaming. This device has considerably less CPU power than ordinary personal computers or laptops. However, many Linux applications run on this device without any or with minimal modifications. Devices like the N770 benefit from the HIP mobility support which enables them to seamlessly change their attachment to different wireless networks while moving. The N770 is a classical example of a HIP host: it is mobile, communicates, and supports a wide range of software which was not specially designed for mobile nodes. Test Tool The measurement process was identical for both systems in order to gain comparable results. We created a measurement tool which allows us to measure the time consumption for different cryptographic operations. This tool uses the same routines as the HIPL implementation in order to yield valid results. It was compiled with the i386 architecture for the server and with the ARM architecture for the N770. The openSSL library provides the necessary cryptographic functions for HIP as well as for our tool. The tool runs on idle standard systems and in parallel to the usual background processes like the swap daemon and the windowing system. Therefore, the measurements are subject to the Linux process scheduling. However, there were no CPU-demanding processes running during the measurements. The tool provides a time resolution of 3 µs on the Xeon server and 30 µs on the N770 which is sufficient for our measurements. The measurement tool is available from the HIP for Linux (HIPL) repository at the HIPL website [Pro].
3.1.2
Performance of the DH Key Exchange
According to the standards, HIP hosts must support 384-bit and 1536-bit DH keys. Therefore, we measured DH key exchanges for these key lengths. We computed five DH public and five DH private keys for each measurement. Combinations of these keys have been used for generating the shared secrets to avoid results which depend on a certain key combination. The results presented in Table 3.1 are the mean times for generating a DH shared key, based on 100 samples. The standard deviation was below 5% for all measurements, except for the short 384-bit key on the tablet. The standard deviation for this result is 12%. The group IDs in the table refer to the Diffie Hellman Groups specified in the HIP base draft. The CPU utilization was almost 100% during the tests.
Group ID 1 3
Key length 384 bits 1576 bits
Table 3.1: Diffie Hellman Xeon 3.2 GHz N770 Key Shared secret Key Shared secret 0.9 ms 0.8 ms 34.1 ms 40.54 ms 19.2 ms 19.3 ms 1,718.8 ms 1,999.4 ms
3.1. Performance Analysis
37
Table 3.1 shows the result of the performance measurement. The DH key generation for g xI mod p and g xR mod p are the same order of magnitude as the shared key generation, g xI xR mod p. In order to generate a shared key, both hosts must generate a public key first. The public key generation can be done before the HIP base exchange while the shared key generation must be done during the BEX because this operation requires the DH public key of the peer. In other words, the DH shared key generation does delay the BEX while the public key generation can be done before the BEX and therefore imposes no delay during the handshake. The comparison between the time used for the DH shared key generation for different key lengths shows that the 1536-bit keys require nearly two seconds of processing on the N770. The shortest DH key length which is supported by HIP is 384 bits. The N770 can generate a shared secret from these keys in 40.5 ms. The DH computations for long keys slow down the BEX and, therefore, increase the delay until the hosts can use the HIP association for communication. However, HIP allows hosts to use short and less secure DH in order to speed up the handshake.
3.1.3
RSA and DSA
HIP uses RSA and DSA signatures to verify the HIs, to protect the BEX packets from manipulation, and to allow middleboxes to authenticate UPDATE packets. We measured the performance of RSA with different key lengths in order to determine the impact of RSA signatures on the weak device. We used a key length range from 512 bits to 3072 bits in order to show the impact of short, intermediate, and long RSA keys on the test systems. The selected five different key lengths are common in practice. However, 512-bit RSA keys are considered unsafe [LLMM00] and should therefore not be used in practice. We calculated five different RSA and DSA key pairs for each key length in order to reduce the probability that the performance measurements depend on a certain RSA or DSA key. The performance measurement results are the arithmetic mean values of 100 signature or verification processes, respectively, with different key combinations. Table 3.2: RSA and DSA Signatures on the Xeon 3.2GHz computer Key length RSA sign RSA verify DSA sign DSA verify Xeon 3.2 GHz 512 bits 2.09 ms 0.06 ms 0.51 ms 0.60 ms 1024 bits 9.09 ms 0.15 ms 1.34 ms 1.61 ms 1536 bits 27.03 ms 0.23 ms 2.18 ms 2.81 ms 2048 bits 65.48 ms 0.42 ms 4.05 ms 4.90 ms 3072 bits 183.14 ms 0.83 ms 8.15 ms 10.65 ms N770 512 bits 30.67 ms 3.23 ms 28.34 ms 34.65 ms 1024 bits 181.32 ms 10.53 ms 96.71 ms 118.73 ms 1536 bits 578.70 ms 23.47 ms 229.27 ms 287.76 ms 2048 bits 1,156.34 ms 35.50 ms 338.88 ms 414.24 ms 3072 bits 4,174.25 ms 90.98 ms 896.02 ms 1,128.73 ms Table 3.2 shows the computation time for the RSA and DSA signatures and signature verification. The standard deviation for the measurements is below 12% for all measurements except the RSA verification for 512- and 1024-bit keys on the N770. The standard deviation for these measurements is 22% (512 bits) and 21% (1024 bits).
38
3. Problem Analysis
The time consumed by RSA verification differs from the time consumed by the RSA signatures by several orders of magnitudes. This is due to the mathematical properties of RSA (see section 2.2.2.2). A small number is chosen as encryption key e — which is used in order to verify signatures. Fast exponentiation techniques enable a fast computation for small e values. The decryption key d, which is used in order to sign messages, is then calculated from e as d = e−1 modϕ(n). This number d depends on e and therefore can not be chosen in a way which reduces the computational overhead of the RSA signature process. The choice of e and d is subject to a tradeoff between the complexities of verification versus signature (cf. Section 2.2.2.2 or [Wät04]). The results for the Xeon server show that hosts with sufficient CPU resources are able to handle the cryptographic overhead of RSA and DSA in time spans of milliseconds. Even long RSA signatures can be computed within 183 ms. Processing times of 183 ms per signature reduce the maximum amount of new connections a server can handle to 5 connections per second at most. However, 3072-bit keys are only required when high security is required which justifies the computational overhead. The measurements on the N770 show that RSA and DSA computations consume processing time in the magnitude of several hundred milliseconds up to seconds. Especially RSA signatures with long keys slow down the tablet for several seconds. The verification of RSA signature is fast. However, verifying a long DSA signature in order to verify the DSA HI of a peer consumes more than one second of CPU time on the N770. Such delays due to long peer keys have to be expected because the host has no influence on the key selection of its peer.
3.1.4
Hash Functions and HMAC
We also measured the performance of the SHA-1 hash function in order to determine the computational overhead of this one way hash function. We applied SHA-1 100,000 times. The mean value for each hash computation was 0.001 ms on the server and 0.018 ms on the Internet Tablet. The server can calculate about one million hashes per second while the N770 is capable of calculating more than 50,000 SHA-1 hashes per second. The HMAC packet authentication requires two hash function computations and two xor operations per signature generation and verification (see section 2.2.3.1). Therefore, it provides a very efficient way to authenticate messages.
3.1.5
Performance of HIP
The performance measurement results show that the cryptographic components of HIP significantly slow down the base exchange and the update process on the N770, depending on the PK keys in use. The initiator as well as the responder have to calculate one signature with their own private key and one signature verification with the public key of their peer during the BEX. Furthermore, they have to compute the DH shared secret. For instance, if both hosts use RSA with 1536-bit keys and 1536-bit DH keys, the PK computations will take 27 ms on the server and 2602 ms on the tablet. No payload traffic between the two hosts can flow before the BEX is completed. Moreover, the CPU is busy during the RSA, DSA, and DH computation. Real-time applications, like streaming audio and video, might experience interruptions during these computations. The least time consuming case is that both, the initiator and the responder, use short keys for the HIs as well as for the DH shared secret. The PK computations during the BEX on
3.2. Problem Statement
39
the Internet tablet for 512 bit RSA keys and 384 bit DH keys take 74 ms. The computations on the server take 1.5 ms. However, short HIs should not be used as long-term identifiers as they can be compromised by attackers (see section 3.5.3 for details). RSA and DSA signatures are also used during the update process. The initiator of an update must sign two packets with RSA or DSA while the responder must sign one message. Furthermore, the hosts may verify the messages of the other peer 1 . Using the same 1536-bit RSA keys as in the previous example, the PK computations during the update consume 1180 ms for the N770, when the tablet acts as initiator and 626 ms when it acts as responder. Consequently, the hosts are disconnected for a longer time period during the handover process. Furthermore, a host must update all its HIP associations after its set of IP addresses has changed. Signing several packets increases the delay even more. Therefore, the update process will take several seconds on weak hosts which communicate with multiple peers. Such a significant delay is unacceptable for streaming and real-time applications (e.g., VOIP, video and audio streaming) and can be assumed to deteriorate the user experience even of less demanding activities such as web browsing. The N770 was not responsive to user input over the graphical interface during our benchmark tests. This shows that even applications which do not use HIP are affected by HIP mobility updates. However, depending on the application scenario, the computational overhead of HIP is appropriate or not. Applications which exchange sensible data require appropriate measures of protection. The use of expensive PK cryptography is adequate for such cases. However, the overhead of HIP slows down applications which do not require such protection unnecessarily. We used the OS 2005 for our measurements. A new Internet Tablet operating system version was released in June, 2006. Many core elements of IT OS 2005 have been rewritten for IT OS 2006. First tests show an increased performance. Testing HIP with this new OS version is future work.
3.2
Problem Statement
The performance test shows that the computation of the cryptographic functions performed during the BEX and during mobility updates endure up to several seconds on our mobile device. Especially the PK operations consumed most of the time while the hash-based operations are inexpensive in terms of CPU cycles. HIP aims at being a general purpose solution. The new namespace and the separation of the IP address and the HI provide a convenient and efficient way to address hosts independently of their location. However, using HIP is only possible if both hosts support the protocol. In order to achieve a widespread deployment, HIP should be applicable to many applications, environments, and platforms. Using HIP for all communication, however, introduces the performance penalties of HIP for all communication flows. Especially on weak devices, these performance issues limit the applicability of HIP in general. For instance, web browsing on mobile devices, with a delay in the magnitude of seconds, may discourage users from using HIP. Web pages with 1 They can also use the HMAC signature instead of verifying RSA or DSA signatures. The RSA and DSA signatures are included in the UPDATE packet to allow verification by middleboxes
40
3. Problem Analysis
contents from several servers even aggravate the situation because clients must establish several HIP associations at the same time in order to display the web page which multiplies the delay. Mobile hosts which establish several HIP associations with different hosts also experience delays of several seconds whenever they change their point of network attachment. We argue that only few users will find such long delays acceptable when it comes to audio streaming or voice telecommunication. Moreover, users will experience CPU load peaks after mobility events which in the worst case freezes all applications for several seconds. This means that even non-networking applications like audio and video players are affected. The question arises if the gain of usability due to mobile support really outweighs the reduced usability due to the HIP performance issues. Peer-to-Peer (P2P) applications even aggravate the situation. Hosts within P2P networks open dozens or hundreds of connections to distinct hosts at the same time and keep these connections open for long time periods. Using HIP in these very popular networks leads to extremely long delays for location updates as a large number of associations must be updated concurrently. However P2P telecommunication applications like Skype [BS04] benefit from the HIP mobility support because, e.g, Internet phone calls are not interrupted after mobility events. Many application cases require neither encryption nor authentication on the network layer. For instance, many web sites do not provide data which requires protection. Moreover, data which requires protection is typically encrypted on higher network layers. Many applications use their own authentication mechanisms and do not rely on lower layers to provide authenticated communication. Consequently, many applications do not necessarily require HIP-based authentication and encryption services. Nevertheless, these applications benefit from HIP-based mobility and multihoming support. Applications with long-lasting connections sustain mobility events and are applicable to mobile hosts without restrictions. One might argue that insufficient CPU resources is a temporary problem for mobile devices and that future generations of mobile devices will have sufficient CPU resources to run HIP without delays. However, increasing the CPU frequency means using more energy. We argue that devices which do not require faster CPUs to perform their basic duties are unlikely to be equipped with fast CPUs just to support HIP because this would require more expensive hardware and more battery resources in order to keep the device running for the same time. Moreover, the additional CPU resources are only required during the load peaks which are caused by the HIP BEX and the update process. Therefore, the CPU would run idle for most of the time in order to provide enough computational power during these peaks. Users of mobile devices have to decide whether they are willing to accept the performance problems of HIP in order to have mobility support. However, the long delays which might even surpass the time which is required to reestablish HIP-less connections after a mobility event might influence the users to favor a HIP-less solutions. We argue that limiting the scope of HIP to applications which require both, security plus mobility or multihoming will, therefore, hinder the deployment of HIP for small mobile devices which would benefit most from it. Moreover, it might hinder the deployment of HIP in general since a large group of devices which actually require the features of HIP will not be able to use it without compromises. Manufacturers and developers might, therefore, favor HIP-less solutions as HIP-enabled devices require more processing power which leads to higher hardware costs. However, wide support from developers and manufactures is essential in order to elevate HIP from an isolated solution for special problems to an omnipresent general purpose solution. We argue that a lightweight version of HIP, which uses the HI namespace and
3.3. Lightweight HIP
41
provides HIP-like mobility support without CPU-intensive operations, is required in order to make HIP attractive for users of weak mobile devices.
3.3
Lightweight HIP
We identified the performance issues of HIP on weak devices. Therefore, our aim is to design a version of HIP which supports end-host mobility and multihoming in a HIPlike way without requiring the hosts to compute CPU-intensive operations. We call the lightweight version of HIP Lightweight HIP (LHIP). The test results presented above show that especially the PK cryptographic operations consume a considerable amount of time. Consequently, our first goal for LHIP is to replace the PK algorithms in HIP. It is clear that, without PK cryptography, LHIP can not provide the same security nor the same functionality as HIP. Therefore, before presenting our LHIP design, we state which requirements for LHIP and what is out of scope for LHIP. We also state an attacker model which defines which kinds of attack LHIP should be resistant against.
3.3.1
Scope of LHIP
The primary goal of LHIP is to increase the performance of HIP on CPU poor devices. Mobile devices, like mobile phones and PDAs with CPU frequencies below 200 MHz, should be able to use LHIP without serious limitations of usability. Without PK cryptography, host authentication, like that provided by HIP, is clearly out of scope for LHIP. Using the same namespace with authentication support requires the same authentication measures as for HIP. We sacrifice host authentication for the sake of performance and assume that applications will use their own authentication mechanisms. Moreover, applications are free to use HIP instead of LHIP in cases which require authentication. An attacker can use LHIP to impersonate a host but it can not cause harm because of the properties of the data or due to higher level authentication mechanisms. Nevertheless, it must neither be possible for an attacker to steal an established HIP or LHIP association, nor may it be possible to impersonate one of the communicating peers during an established HIP association. Protection against MITM attackers during the BEX is difficult to achieve without verifying the cryptographic properties of the HIs. We assume that no such attacker is present during the BEX and that the BEX is unmodified. Furthermore, we assume that applications implement measures to identify these attacks if such protection is necessary. Alternatively, HIP-aware applications can decide to use HIP instead of LHIP. Payload encryption and authentication is also out of scope for LHIP. We trust that the transport layer and the upper layers provide adequate measures to authenticate and encrypt data. However, the proposed protocol should provide protection against MITM attacks which take place after the BEX. We assume that a MITM can be on the communication path after location changes or after multihoming events. This assumption is important in order to support mobile devices. Frequent subnetwork changes should not endanger the security of the protocol. The way HIP works should not change in general which means that the concept of decentralized end-host mobility and the way HIP provides its services should not be altered.
42
3. Problem Analysis
LHIP should provide the same functionality as HIP does but without authentication and encryption. However, we need to replace certain mechanisms in HIP and to introduce new techniques in order to gain performance. LHIP should use the same namespace and the same name resolution infrastructures as HIP does. It should not be necessary to deploy a second namespace infrastructure for LHIP. LHIP should also support middleboxes and network infrastructure elements in a similar way as HIP but host authentication for middleboxes is also out of its scope. Above all, LHIP must provide basic protection and security. In other words, LHIP must not allow attacks which are worse or easier to mount than attacks without LHIP.
3.3.2
Threat Model
We define a threat model which enables us to identify which kinds of attackers and attacks have to be expected for a lightweight version of HIP. • We assume that an attacker can receive all packets, including the BEX and UPDATE packets. • The attacker can modify, drop, resend, duplicate and delay packets. However, we assume that the attacker does not take active measures during the BEX. • The attacker has more CPU resources than the victim. However, the attacker can not compute calculations which are considered to be computationally infeasible. In particular, an attacker can not reverse hash functions nor can it forge RSA or DSA signatures. The LHIP design must be able to cope with such an attacker and should provide adequate measures to prevent attacks from such an attacker.
3.4
HIP High-level Goals
HIP uses a wide range of different cryptographic mechanisms in order to achieve security, confidentiality and authentication. We analyze how these security mechanisms are used in HIP in order to find ways to improve the performance of HIP. HIP achieves three high-level goals in terms of security: payload security, protocol security, and safe host authentication which we refer to as namespace security. H1: Payload security ensures that the access to payload, transferred by HIP, is restricted to the peers which share the same HIP context. Two hosts can send data over insecure communication channels in a secure way. It is computationally infeasible for an attacker to decrypt the transferred payload. Furthermore, an attacker can not manipulate the payload unnoticedly. H2: Protocol security ensures that the communication protocol is not susceptible to malicious interactions with attackers or misbehaving peers and network components. An attacker can not influence the protocol behavior in a way which causes harm to one of the communicating peers or any other third party. A secure protocol must be able to prevent and discover accidental or intended misuse which leads to limited
3.4. HIP High-level Goals
43
Figure 3.1: HIP high-level goals and dependencies between techniques, protocols and algorithms which are employed to achieve the goals. functionality. Protocol security is not restricted to the communicating peers only, but also includes considerations about the communication channel and intermediate nodes like gateways which directly or indirectly participate in the communication process. H3: Namespace security enables trustworthy communication between hosts and provides a way to securely address hosts, using HIP. Namespace security mechanisms must protect the namespace from intended or accidental misuse. Above all, HIP must provide protection against identity theft and impersonation. A combination of different techniques and cryptographic protocols ensures each of these goals. Figure 3.1 depicts the high-level goals and the techniques which are used to achieve them. Some of these techniques depend on other techniques. The illustration depicts these dependencies. It shows a directed dependency graph between high-level goals and cryptographic techniques, protocols, and algorithms. HIP achieves these high-level goals by combining several security mechanisms and algorithms. HIP strongly relies on PK cryptography. The protocol enforces protocol security by utilizing RSA, and HMAC signatures. These signatures ensure that packets have been sent by the legitimate peer. The HMAC algorithm requires a shared secret which both peers must possess. This shared secret is provided by the Diffie Hellman key exchange. The key exchange is protected with RSA signatures to ensures that the DH parameters have not
44
3. Problem Analysis
been modified by a man-in-the-middle attacker. RSA signatures are also used in UPDATE packets, since middleboxes, such as gateways can not use the HMAC signatures to verify packet authenticity and integrity because they are not in possession of the shared secret. The high-level goal of protocol security is, therefore, reached by utilizing RSA, HMAC signatures, and the Diffie Hellman key exchange. Payload security for HIP is provided using the ESP which utilizes symmetric encryption algorithms to protect the payload. These encryption algorithms require both hosts to share secret symmetric keys. These keys are generated during the authenticated Diffie Hellman key exchange. Payload security, therefore, depends on the ESP protocol, the Diffie Hellman key exchange and RSA signatures. Namespace security and host authentication depend on RSA signatures. Signing R1, I2, and R2 packets with the private key belonging to a HI guarantees that the host is using its own identifier. The RSA signature reveals spoofed identifiers. Figure 3.1 shows a directed graph of dependencies. For instance, the HMAC algorithm can only provide protocol security if a shared secret was provided with the DH key generation. Furthermore, statements about the identity of a host are only possible if the DH key exchange was authenticated. Removing the RSA signatures or the DH algorithm would render the HMAC algorithm useless. The dependency graph shows that all the security features of HIP are based on PK cryptography. Removing the PK algorithms for the sake of performance leaves HIP without appropriate measures to provide protocol, payload, and namespace security.
3.4.1
LHIP High-level Goals
The dedicated goal of LHIP is to reduce the computational cost of HIP while retaining the high-level goals H2 -protocol and H3 - namespace security. However, we relax the goal H3. We only require that the namespace can not be used for attacks which are worse than attacks on TCP/IP. Host authentication is not required as long as identity theft during the lifetime of an LHIP association is not possible. We require the weak authentication property of temporal separation. A host must be able to relate communication during a HIP association to communication at an earlier point in time, during the BEX. The high-level goal H1 - payload security is sacrificed for the sake of performance. However, the level of payload security should still be comparable to the one offered by plain TCP/IP. Furthermore, we define compatibility with the HIP base exchange, and therefore interoperability with HIP and upgradability from LHIP to HIP as further concrete goals. Upgradability refers to the ability of hosts to transfer an LHIP association into a HIP association without tearing down and re-opening the association. These three concrete goals are summarized in the new high-level goal compatibility. We define the high-level goals of LHIP as: LH1: Increased performance for weak devices. The performance penalties of PK cryptography should be reduced to an amount which is acceptable for the use on mobile devices with little CPU power. Especially the delays during the BEX and the connection disruption during updates are noticed by the users. Therefore, we require LHIP to reduce the computational cost of the BEX and the update process to 10% of the processing cost of HIP with 1024-bit RSA or DSA HIs.
3.5. Possible Approaches
45
LH2: Protocol security must be provided in LHIP. The protocol should not allow attacks which are worse than today’s attack on TCP/IP. This includes attacks on the communicating peers, third parties, and infrastructure elements like middleboxes. LH3: Namespace security should be provided to a certain extent. Host authentication is not required but attackers must not be able to impersonate a communication peer during the lifetime of a LHIP association. Furthermore, LHIP must be able to deal with namespace conflicts. The relaxed goal of host authentication must not yield new ways of attacking HIP or LHIP hosts. LH4: Compatibility with the HIP protocol should be provided to a certain extent. Infrastructure elements like name resolution services should be used by HIP and LHIP in the same way. LHIP should resemble HIP and provide the same functionality regarding mobility and multihoming support. LHIP should extend HIP rather than defining a new HIP-like protocol. The message format and the packet contents should not differ much from HIP packets to reduce the implementation overhead for hybrid HIP and LHIP implementations. Furthermore, middleboxes should be able to learn about new IP addresses of hosts and new SPI values in a safe way. LHIP associations should be upgradable to HIP associations during their lifetime without the need to close and reestablish the association. Additionally, compatibility with legacy applications should also be provided the same way as in HIP. The requirements stated above can be summarized as: Modifying the HIP protocol in order to achieve safe mobility and multihoming for TCP/IP without payload encryption and host authentication. The HIP dependency graph in figure 3.1 shows that ESP encryption and, therefore, the high-level goal H1,payload security, can be removed from HIP without affecting the other high-level goals. However, the vector for performance improvements, reached by removing payload encryption is limited. Furthermore, the ESP protocol does not influence the long connection establishment delay on weak devices. A much greater gain in performance can be achieved by reducing the use of PK cryptography during the base exchange and the update process. We focus on this challenge to make HIP applicable to weak devices.
3.5
Possible Approaches
We first discuss three simple approaches to reduce the amount of PK operations in HIP. These approaches show that it is not trivial to speed up the HIP protocol. All of these trivial approaches either violate one of the desired high-level goals or only achieve insufficient performance improvements.
3.5.1
Remove Diffie Hellman
Our first trivial solution is to remove the Diffie Hellman key exchange while keeping all other protocol functions as they are. This solution obviously reduces the cost of establishing a new HIP association since the CPU-intensive DH shared key computations are omitted. However, it also affects the symmetric cryptographic elements and the hashed message authentication codes because no shared keys are provided anymore. A shared key for ESP is not needed in LHIP as payload encryption is not necessary. ESP can operate in NULL mode which does not require a shared key. This mode does not encrypt the payload and,
46
3. Problem Analysis
therefore, can be used without shared keys. Still, a shared secret is required for calculating the HMAC signatures. We also remove the HMAC signatures since we can not calculate them any more without a shared secret. HIP uses HMACs and RSA to authenticate HIP control messages. The security properties of RSA are sufficient to provide adequate authentication. Moreover, the RSA signatures have to be used in any case to enable middleboxes to authenticate UPDATE and CLOSE messages. So far, this approach seems to achieve the desired high-level goals. RSA signature verification is much more CPU-intensive than HMAC verification is. The absence of the HMAC signature means that the peers can not check the authenticity of UPDATE messages in a cost-efficient way before calculating expensive PK operations. This introduces a new weakness which can be exploited for DoS attacks. Both LHIP peers, the weak client as well as its peer —possibly a commercial server—, become susceptible to attacks which aim at CPU-cycle consumption. The RSA signatures would always have to be checked without any possibility to filter out forged messages from an attacker. An attacker that is aware of the HIP associations of a victim can send invalid UPDATE messages with spoofed host identifiers. The attacker can use the HIs of the victim’s peers. The victim can only filter out the forged messages by verifying the RSA or DSA signatures while the attacker can send random bits as forged RSA and DSA signatures. This gives the attacker an advantage over the victim and provides an efficient way to consume large amounts of CPU cycles on the target host. Due to this weakness, the first approach can not achieve the second high-level goal LH2, protocol security.
3.5.2
Remove DSA/RSA
The first approach showed that an attacker can use unprotected RSA signatures for attacks. Furthermore, these signature cause an inacceptable amount of computational overhead during the BEX and during the update process. As stated above, host authentication is not a necessary requirement for LHIP. Therefore, removing RSA from HIP could be considered an option. The Diffie Hellman key exchange generates a shared secret which can be used for host authentication during the lifetime of a HIP association. The HMAC in the UPDATE messages provides authentication for the communication peers. This is sufficient to provide weak authentication with temporal separation. Provided that the BEX is authentic, an attacker can not impersonate one of the communication peers during the lifetime of the association. However, the computationally expensive DH key exchange is still required for creating the shared secret. Furthermore, middleboxes have no means of verifying the authenticity of UPDATE messages. The missing RSA signatures leave them no secure option to learn of updated IP addresses or new SPIs. This limits the usability of LHIP with packet inspecting middleboxes since they will not support HIP mobility without authenticated updates. Alternatively, it will make new attacks on middleboxes possible if these react to unauthenticated HIP UPDATE messages. Again, the second high-level goal can not be achieved by removing RSA from HIP. Moreover, completely removing RSA from HIP enables attackers to use spoofed HIs. The legitimate owner of a HI has no means of proving its identity to a remote host. This raises severe security issues, especially when HIP and an RSA-less version of HIP are used in parallel. The high-level goal LH3 - namespace security can, therefore, not be achieved without RSA.
3.5. Possible Approaches
3.5.3
47
Reduction of the Key Size
One could argue that HIP, as it is, offers enough speed-up potential to support weak devices. RSA as well as the Diffie Hellman key exchange can use keys of different length. Short RSA keys could be used to generate weaker identifiers and short DH keys could be used to generate weak session keys. These session keys do not offer sufficient security for long-term data security but provide short-term keys for the HMAC authentication. The potential for improvements is limited to medium-sized keys as very short RSA and DH public keys are easy to compromise and should not be used. A host could choose medium-sized keys to lower its processing cost of generating signatures and calculating a shared secret. However, it still needs to verify the HIs of the peer. Especially the verification of long DSA HIs is CPU-intensive. The weak device can not lower the verification cost for these keys, since it has no influence on the key length selection of its peer. Consequently, a server that wants to support weak clients as well as clients with sufficient CPU power either has to lower its provided level of security for all hosts or it must use different identifiers for weak hosts. Using two identifiers leads to practical problems when the identifiers are passed from one host to another. It also complicates the mapping between a host and its identifiers. Especially legacy applications have no means to express which keys should be used and which level of identifier hardness is required. This conflicts with goal four — LH4 - compatibility. One solution to this dilemma could be to compile several keys into one identifier. The HIT would be the hash over all these keys. This would tie these keys together. However, this makes key revocation difficult. Identifier components can not be changed without changing the whole identifier and the HITs which are generated from them. This would make compound identifiers short lived and would seriously reduce the usability of the host identity namespace. Hence, decreasing the key length would violate goal LH3 - namespace security or LH4 - compatibility.
3.5.4
LHIP Approach
The previous paragraphs pointed out that a non-trivial solution is necessary to provide efficient mobility and multihoming in a secure way. The following sections will introduce our LHIP approach, discuss its advantages and disadvantages, and demonstrate its effectiveness and practical usefulness.
48
3. Problem Analysis
4. Design In this chapter, we present the design and the rationale of our lightweight version of HIP, LHIP. The chapter consists of five sections. The section 4.1 discusses hash chains as alternative to PK-based cryptography. In sections 4.2 and 4.3, we introduce a lightweight authentication layer based on hash chains which enables message authentication with little computational overhead. Section 4.4 identifies weaknesses which arise if the HI namespace is not protected by PK cryptography. Section 4.5 shows how an LHIP association can be transformed into a HIP association. The previous chapter pointed out that the high-level goals for a lightweight version of HIP can not be reached by removing the PK operations alone. Nevertheless, hosts with little processing power require alternative authentication mechanisms which reduce the computational cost of HIP. However, there are no computationally inexpensive algorithms with identical properties. Hash chains, however, offer an efficient way to authenticate messages without a shared secret. Their way of application and their security properties differ from DH-generated shared secrets. Despite the differences they are an alternative to DH and RSA in the context of HIP. Our LHIP approach is an extension to HIP. It uses the functionality of HIP to establish, to update, and to close an LHIP association. We modified the HIP protocol and extended it to meet the security requirements stated above while achieving better performance. The basic cryptographic primitives of LHIP are hash chains. LHIP uses them to authenticate messages. The hash chain anchors are exchanged during the LHIP base exchange. According to our threat model, we assume that no active MITM attack is performed during the BEX. This assumption and the relaxed high-level goal LH3 - namespace security allow us to use RSA signatures only in cases of conflicts and namespace violations. Hash-chainbased signatures provide authentication for LHIP control messages. Since middleboxes can also verify the hash chain signatures, there is no need for RSA signatures in these packets. Provided that no namespace violations occur, LHIP can operate completely without computing PK operations. However, LHIP relies on RSA and DSA signatures in case of namespace conflicts. Figure 4.1 illustrates the dependencies between the employed cryptographic techniques and the LHIP high-level goals. The abstract high-level goals of
50
4. Design
Figure 4.1: LHIP high-level goals and dependencies between techniques, protocols and algorithms which are employed to achieve them. The abstract high-level goals performance and compatibility are not depicted. Optional processes are indicated by dashed lines. performance and compatibility are not depicted as they depend on the proposed design rather than on concrete mechanisms. Optional processes are indicated by dashed lines.
4.1
Hash Chains for HIP Authentication
This section discusses the advantages and disadvantages of the three signature mechanisms based on hash chains (cf. section 2.2.3.2 and following) each approach in the context of LHIP.
4.1.1
One-time Signatures
One-time signatures, which use Lamport’s and Merkle’s signature scheme, allow instant signature verification. However, they impose a higher computational overhead than the other approaches. The time-based approach, as well as the interactive approach, require the use and verification of only one hash chain element per signature. In contrast to these approaches, signature schemes based on Merkle’s approach use l + blog2 (l)c + 1 hash chains to sign an l-bit message digest. The typical message digest length which is used for signatures in HIP is 160 bits. This means that 160 hash chains and, therefore, 160 anchor values must be exchanged during the base exchange. The average number of hashes contained in each signature is l+blog22 (l)c+1 . This means that about 84 hash computations are necessary to sign and verify each UPDATE message. Moreover, about 84 hashes must be
4.1. Hash Chains for HIP Authentication
51
transmitted as signature. Assuming that SHA-1 hashes are used, the signature alone would use an average of 1680 bytes of the space reserved for the HIP parameters is at most 2008 bytes long. The maximum size of a signature is 3300 bytes1 which exceeds the maximum length of the HIP parameter field. Winternitz’s approach reduces the size of the signature but increases the computational cost even more, which is not desirable for LHIP.
4.1.2
Time-Based Hash Chain Signatures
TESLA requires only one hash chain for signatures and the disclosure of one hash chain element per time interval. The signature is the same size as a regular HMAC signature. Therefore, signature generation and verification require only a fraction of the space and computational power required for one-time signatures based on Merkle’s scheme. However, the time-based verification delay renders these hash signature inapplicable to HIP for the reasons explained below. TESLA is designed for scenarios where a sender periodically sends data. In contrast to periodical messages sent by TESLA, HIP control messages are sent sporadically. The time span between HIP control messages typically ranges from seconds to hours as hosts only send control messages to notify IP address changes or to close HIP connections. The time-based approach uses one hash chain element per signature lifetime period. This fixed cost is required no matter whether data is sent or not. Short lifetime periods lead to an unnecessary computational overhead as many hash chain elements would be disclosed without being used for signatures. For instance, a lifetime of 300 ms would use 12000 hash chain elements per hour, regardless of whether an UPDATE message is sent or not. The cost for the hash chain generation would, therefore, exceed the cost for the Diffie Hellman key generation for many associations. Longer hash chain element lifetimes reduce the overhead but also increase the time it takes to verify a signature. This would lead to slow mobility updates in LHIP. Since all transport layer connections are disrupted until the mobility update has been finished, slow updates affect and might even break these connections. Even a hash chain element lifetime of two seconds would delay the update process for up to six seconds. Such long interruptions cause problems with delay-sensitive applications like video or audio streaming.
4.1.3
Interactive Approach
The interactive approach discloses hash chain elements only when messages are signed with them. This behavior is suitable for infrequent UPDATE messages. The computational overhead of the interactive approach is slightly higher but of the same magnitude as the overhead of TESLA. The size of the signature is the same as the size of an HMAC signature. The hash anchors are single hash values and only few hash chain elements are disclosed during the signature process. The delay until a host can verify a signature depends on the RTT between the communicating peers. The additional delay for the three-way HIP update process is expected to be in the order of three RTTs. While expensive, this is not a prohibitive overhead for the adoption of this scheme in LHIP. We decided to use interactive hash chain signatures as their tradeoff between signature size, computational overhead, and verification delay is suitable for location updates. We use 1 This number derives from the maximum number of 1 bits in the message digest and the 1-bit count field. The signature contains 159 1 bits and 6 one bits in the binary representation of 159. This means that the signature consists of 165 hashes.
52
4. Design
the abbreviation IHC for Interactive Hash Chain in the following sections. Like WIMP (cf. section 2.2.6.1), our approach uses IHC signatures in order to secure mobility and multihoming update messages. However, we tried not to design a new IHC signature protocol but we use IHC signatures to extend the HIP protocol.
4.2
LHIP Authentication Layer
Hash chains can not provide the same level of security nor can they be used in the same way as shared secrets. They only provide temporary secrets. IHC signatures differ in three ways from regular HMAC signatures which have been created with a shared secret. First, messages can not be verified instantly. Hence, the receiver of a message must buffer it until it receives the hash chain element which is required for the verification. Second, two hash chain elements of an identical hash chain must never be on the wire at the same time. This requires queueing messages and sending signed messages one by one. Third, the interaction which is necessary to deliver a signed message is more complex than for shared secret HMACs. Packet loss, retransmissions, duplicate packets, invalid messages, and undeliverable packets must be handled with respect to the security properties of hash chains. For these three differences, hash-chain-based HMAC signatures turn out to be more complex in handling than their conventional relatives. Integrating IHC signatures tightly into HIP would complicate the protocol and require complex modifications to HIP. Instead, we define a new authentication layer which extends HIP. The authentication layer is transparent for most of the functionality of HIP. This allows us to reuse nearly all of the mechanisms that HIP utilizes to provide secure mobility and multihoming. The isolated authentication layer ensures message authenticity with hash chains while HIP can create and process packets as if a shared secret was present. Figure 4.2 illustrates the LHIP authentication layer and the way it interacts with HIP. The authentication layer accepts unsigned control messages from HIP and determines whether it must apply a signature or not. This is determined by the HIP header type and the message contents. The authentication layer enqueues all messages which require protection and sends them one by one. The authentication layer takes care of the necessary interaction messages, which are required for IHC signatures. These packets are not passed to the HIP layer but are handled by the authentication layer. The authentication layer verifies that all signed messages are valid. It handles tasks like packet retransmissions, duplicate packets, and provides support for undeliverable packets.
4.2.1
Improved IHC Signatures
The interactive hash chain approach leaves some space for improvements which provide better resilience against man-in-the-middle attacks, simpler packet handling, and increased efficiency for acknowledged messages. We introduce three improvements: dedicated hash chains, pre-signatures, and pre-acknowledgements. These improvements are based on the second preimage resistance and collision resistance of cryptographic hash functions. They simplify the state machine of the authentication layer and avoid some security issues. We assume that both hosts use the same cryptographic hash function H. The output length of H is l bits. We use a 160-bit output length for practical examples. The popular hash function SHA-1, for example, generates 160 bit output.
4.2. LHIP Authentication Layer
53
Figure 4.2: The LHIP authentication layer handles the authentication of messages which require this service. It handles the interaction necessary for IHC signatures. Payload is sent encapsulated into unencrypted ESP packets.
54
4. Design
Figure 4.3: MITM attack on an IHC signature scheme which uses only one hash chain per host. An attacker can exploit simultaneous messages. 4.2.1.1
Dedicated Hash Chains
The IHC signature approach of Torvinen and Ylitalo uses one hash chain on the sender and one hash chain on the receiver side. Both hosts can exchange authenticated messages over insecure channels. However, this scheme is not secure when it is used for mobility updates like they are performed by HIP. Hosts may change their location at any time. Both hosts may even change their location concurrently. This states the requirement that each host must be able to send UPDATE messages at any time. An MITM attacker can mount an attack whenever both hosts send their next hash chain element at the same time due to simultaneous location updates. Figure 4.3 illustrates the attack. Assumed host A and host B have established a communication context and have exchanged their hash chain anchors B hA i+1 and hi+1 earlier. The superscript of h indicates which host the hash chain element belongs to. Both hosts decide to send a signed message at the same time. A man-in-the-middle attacker M can delay both of the packets and use the hash chain B element hB i to acknowledge A’s message before B has received it. It sends hi to host A. This is interpreted as valid acknowledgement that host B has received the first message from A. A will react to the acknowledgement by disclosing hA i−1 . The attacker is now in A A possession of hi and hi−1 though B has never acknowledged the receipt of hA i . Therefore, it will accept messages which are signed with hA . The attacker can now generate a valid i−1 signature for an arbitrary message which appears to be signed by A. The main problem of this IHC signature scheme is that A can not distinguish hash values of B, which are meant for acknowledgements from hash values that are meant for signatures. We use two dedicated hash chains per host to avoid this situation. Every host generates a signature chain and a trigger chain. Signatures are created with elements from the
4.2. LHIP Authentication Layer
55
Figure 4.4: Two hosts use one signature chain and one trigger chain per host. signature chain while acknowledgements use hash chain elements from the trigger chain. The trigger chain elements trigger the release of the next hash chain element of the sender’s signature chain. Figure 4.4 shows two hosts which use dedicated hash chains to establish a bidirectional duplex channel. Both hosts exchange the two anchors during the BEX. After the exchange, a host can send updates whenever it is necessary. Even simultaneous updates are no threat to this construction because an attacker can not sign messages with hash chain elements from a trigger chain nor can it acknowledge messages with elements from a signature chain. Using two hash chains per host does not increase the overhead because IHC signatures, with and without dedicated chains, use one hash chain element on each side. The only additional effort comes from exchanging two hash chain anchors per host instead of one. Both hosts can start the signature process whenever necessary. However, a host can not send any further signed messages during the signature process. Using one pair of hash chains per host creates one duplex channel. Consequently, multiple channels can be created by utilizing multiple pairs of hash chains. Several channels enable parallel signature interaction handling and, therefore, reduce delays. Figure 4.5 shows two hosts with several IHC-signature-protected channels. However, the sequential way in which HIP handles UPDATE messages does not require such parallel channels. 4.2.1.2
Pre-signatures
The original IHC signature approach consists of three packets for one signed message. The first packet contains a hash chain element hi , the message m and the HMAC which is generated from m and the next undisclosed hash chain element hi−1 . This packet must be buffered by the receiver and can not be verified before hi−1 has been disclosed by the sender. This scheme bears some problems. For example, it requires strict serialization. Multiple messages can not be sent at once as only one hash chain element may be on the wire at the same time. Packing several UPDATE messages into one signed packet is not possible in general as the number of bytes per packet is limited by the maximal packet size defined by HIP. Sending several messages signed with one hash chain element collides with the interactive scheme. This considerably reduces the maximum throughput. We propose to not send the actual message in the first packet but to send it in the second packet from the sender to the receiver. The first packet only contains the sender’s next hash value hSi and the signature HM AC(hSi−1 , m). The receiver acknowledges this packet with
56
4. Design
Figure 4.5: Two hosts use several pairs of signatures and a trigger chain. a hash chain element of its trigger chain. Consequently, the sender discloses hSi−1 and the message m in a second packet. Figure 4.6 illustrates this process. We call the signature without the message pre-signature as it signs a message which is sent later. Pre-signatures offer four appealing advantages. Not all of these advantages are necessary to protect HIP UPDATE messages. We state these advantages, nevertheless, as they might be beneficial for other protocols. Small size The responder must buffer the first message of the IHC signatures in order to verify it with the hash chain element from the second message later on. Using pre-signatures instead of messages plus signatures reduces the amount of data which must be buffered. The benefit for end-hosts is marginal as they probably have enough memory to buffer the signatures plus the messages. In contrast, memory is a scarce resource on middleboxes, like firewalls and NAT boxes. Moreover, middleboxes need fast access to the memory in order to achieve high throughput. These packetforwarding middleboxes must buffer the first of the IHC signature messages in order to verify the signatures. Using pre-signatures drastically reduces the amount of memory which is required for message authentication on middleboxes. Only the small pre-signature must be buffered. The middlebox buffers the small pre-signature instead of the larger cleartext message. Moreover, pre-signatures reduce the amount of data which is written into the memory and read from the memory of the middlebox. Details on how middleboxes verify IHC signatures are provided in section 4.3.3. Cumulative transmission Many pre-signatures fit into one HIP control packet because of their small size. Therefore, many pre-signatures can be placed at the receiver side with one message. All of these pre-signatures are generated with the same undisclosed hash chain element. The receiver acknowledges the receipt of a cumulative
4.2. LHIP Authentication Layer
57
Figure 4.6: Interactive hash chain signatures with pre-signatures. The message is sent in the third packet instead of in the first packet.
pre-signature just as it would acknowledge a single pre-signature. The sender can now send all messages which have been pre-signed in parallel. This increases the performance of the system.
Efficient retransmission A signature can only be verified if both packets from the sender to the receiver are transmitted without any errors. In the case the first packet is erroneous, the first packet must be retransmitted while both packets must be retransmitted in case the second packet is erroneous. This means that the first packet requires to be retransmitted in every error case while the second packet only needs to be retransmitted when an error occurs in the second packet. Sending the actual message m in the first packet means that the large message needs to be retransmitted in both error cases. Placing m in the second packet means that m only must be retransmitted if an error occurs in the second packet. Therefore, it is less likely that the potentially large message m has to be retransmitted.
Confidentiality The original IHC signature scheme places the cleartext message m in the first packet. However, the receiver can not use this message until it is verified by using the hash chain element disclosed in the second packet. An attacker, however, can read and use the message from the packet under the assumption that it is authentic. This assumption gives the attacker an advantage. It gains knowledge of the message and can react to the message before the receiver can use the message. The attacker can use this knowledge to foresee and disturb the actions of the receiver. Pre-signatures do not reveal the message until it can be verified. The first packet contains only a hashed information. An attacker can not use the interval before the message is verifiable to react to it. This is important whenever two or more parties request access to a limited resource. Prior knowledge of the message gives an attacker an unfair advantage. LHIP does not necessarily require confidentiality. However, it might turn out beneficial for interaction with certain kinds of LHIP-aware middleboxes.
58 4.2.1.3
4. Design Pre-acknowledgements
Each signed message from a sender S to a receiver R requires a three-way IHC signature process. Sending a signed acknowledgement for a signed message requires another set of three packets. We reduce this overhead by introducing pre-acknowledgements (PACK) and pre-negative acknowledgements (PNACK). The pre-acknowledgements contain pre-signed acknowledgements like the pre-signatures contain pre-signed messages. They contain hashed information which enables S to verify whether R has sent an acknowledgement or a negative acknowledgement. Figure 4.7 depicts the signature process with pre-acknowledgements. R generates the PACK and PNACK value after it receives the pre-signature. At this point it is unclear whether the signature process will be successful or not. Therefore, it creates pre-signatures of acknowledgements for both cases: PACKs and PNACKs. It uses a constant number constack and constnack as messages and creates pre-signatures with the next undisclosed hash chain element hR i−1 . However, using ordinary pre-signatures for acknowledgements would mean that the acknowledgement as well as the negative acknowledgements would be signed. S could verify the PACK as well as the PNACK value. To avoid this, R includes a secret number secretack in the PACK value. Analogously, R includes a different secret number secretnack in the PNACK value. An attacker can not forge these values as they contain an undisclosed element of the hash chain of S. The PACK and PNACK values are created as follows:
P ACK = H(constack k secretack k hR i−1 ) P N ACK = H(constnack k secretnack k hR i−1 )
(4.1) (4.2)
R sends back both values in the second packet of the IHC signature process. S stores both values and waits for R to disclose its next hash chain element and the secretack or the secretnack value. R sends a fourth packet when it receives the third packet and verifies the signature of the message contained in it. R sends back an acknowledgement or negative acknowledgement in a packet containing hR i−1 as trigger value and secretack or secretnack as acknowledgement or negative acknowledgement. S verifies the acknowledgement by using formula 4.1 with the disclosed values. The constant values constack and constnack are publicly known. The acknowledgement is valid if the result matches the PACK value sent in the second packet of the IHC signature process. The corresponding check is done for negative acknowledgements with formula 4.2 in case secretnack is contained in the fourth packet. All of the contents of the PACK and PNACK values (secretack / secretnack , constack / constnack , and hR i+1 ) have a fixed length to avoid length extension attacks on the hash function (see section 2.2.3.1). R has to choose new values for secretack and secretnack for every acknowledgement. Otherwise an attacker can use previously used secrets to forge acknowledgements and negative acknowledgements. It could, for example, replace the acknowledgement secret in the fourth packet by a negative acknowledgement secret which was used and disclosed earlier. This secret would pass the verification test because R uses the same secrets for all PNACK values. Therefore, unique secrets are essential for the protocol to function properly.
4.2. LHIP Authentication Layer
59
Figure 4.7: Interactive hash chain signatures with pre-acknowledgements. The second packet contains pre-signed acknowledgement and negative acknowledgement values. These can be verified with the values disclosed in the fourth packet. Using PACK and PNACK values enables acknowledgements for signed messages with only one additional packet. They are efficient to compute and to verify as only few hash operations are necessary. Their usage saves two packets and one RTT respectively, compared to signed acknowledgements without PACK and PNACK.
4.2.2
Terminology
Before we continue, we first need to introduce some abbreviations and clarify some terms to make the following sections easier to understand. During the following sections the term sender will denote the host which initiates the signature process while the term receiver denotes its peer. 4.2.2.1
Packet Types
Figure 4.8 summarizes the terms which are used for our IHC signature approach. We call the first packet of the IHC signature scheme a PSIG packet as it contains the pre-signature. The second packet is called TRIG packet because it contains the trigger value which triggers the release of the undisclosed hash chain element which was used for the pre-signature. The third packet is called MSG packet as it contains the actual message which must be delivered. The last packet is denoted ACK packet because it contains the acknowledgement or negative acknowledgement secret. 4.2.2.2 Trigger Values The trigger values are the cleartext hash chain elements contained in every IHC signature packet. Recall that the sender always takes hash chain elements from its signature chain while the receiver always uses its trigger chain. The different hash chains are not depicted in figures nor are they indicated in formulas for simplicity’s sake.
60
4. Design
Figure 4.8: Terms used in our IHC signature approach. 4.2.2.3
Valid, Old, and Invalid Hash Chain Elements
Depending whether a hash value belongs to a hash chain or not and depending on when it was disclosed, we classify hash chain elements into classes: valid, old, and invalid elements. • A hash chain element is valid when it is the predecessor of the most recently disclosed hash chain element of the same hash chain. When, for instance, hi is the last hash chain element disclosed by a host, only the value hi−1 , which fulfills the equation H(hi−1 ) = hi is considered to be valid. • A hash chain element is old when it equals the most recently disclosed hash chain element of the corresponding hash chain. Hosts consider elements to be old if they already have received the same element but not its successor. Assumed hi is the last hash chain element disclosed by a host, further packets with hi as trigger value are considered old. • A hash chain element is invalid when it is neither old nor valid.
4.2.3
State Machines
The authentication layer provides message authenticity with the IHC signature scheme proposed above. This scheme assumes that messages are sent one by one and that no IHC signature packets are lost or corrupted. Our state machine handles errors like packet loss, packet duplication, and corruption. The authentication layers of the sender and the receiver have different state machines. Each LHIP host must implement both state machines in order to send and receive IHCsigned messages. There are two packet types the sender may send: pre-signature packets
4.2. LHIP Authentication Layer
61
(PSIG) and message packets (MSG). The receiver may send trigger packets (TRIG) and acknowledgement packets (ACK). Each packet contains a hash chain element which proves that the legitimate host has sent the packet. The hash chain element can not authenticate the packet contents. Nevertheless, it indicates that the host has sent some packet. If both hosts follow the IHC signature protocol, a host can tell from the trigger value that the remote peer has received its last packet and that its last own hash chain element is not on the wire any more. Both hosts, the sender as well as the receiver, will only process packets with old or valid trigger values. Neither of them may processes packets with invalid trigger values. These packets are silently dropped. 4.2.3.1
Sender State Machine
Figure 4.9 illustrates the state machine for the sender’s authentication layer. It consists of three states and seven possible transitions. State loss due to host resets is not handled in this state machine as the HIP association would be lost as well. The hosts would first need to reestablish their HIP association and exchange new hash chain anchors. It is neither possible nor sensible to continue the signature process of messages which belong to an outdated HIP association. State Ready The signature process starts in state ready. In this state, the sender drops all TRIG and ACK packets as they must belong to a previous signature process. A new signature process is triggered when HIP hands over a control message to the authentication layer. The authentication layer of the sender buffers the message, creates the pre-signature with the next undisclosed hash chain element, sends the PSIG packet, and transitions to state PSIG sent. State PSIG Sent The sender starts a timer which determines when to retransmit the previously sent PSIG packet. It waits for a valid TRIG packet from the receiver. This TRIG packet must contain a valid hash chain element of the receiver’s trigger hash chain. TRIG packets with invalid hash chain elements are dropped and not processed any further. ACK packets are dropped in state PSIG sent as they must be old retransmissions from previous signature processes. The sender retransmits the PSIG packet without using a new hash chain element if the timer times out. This retransmission ensures that the signature process continues in case the PSIG packet or the TRIG packet from the receiver was lost due to transmission errors. The sender waits for a valid TRIG message which consists of a valid trigger value and the PACK and PNACK values. The sender buffers the PACK and the PNACK values as they are needed to verify the contents of the ACK packet later on. The sender continues the signature process by sending the MSG packet that contains the original HIP message and its next hash chain element. Recall that this element was used to generate the pre-signature in the PSIG packet. The sender transitions to state MSG sent after sending the MSG packet. The sender may also cancel the signature process and send another pre-signature packet after it received the TRIG packet from the receiver. This enables priority messages to override running pre-signature processes. It is important to note that a sender can only cancel a signature process after it receives a TRIG or an ACK packet from the receiver. Every other time of sending a new pre-signature would allow attacks because several sequential hash chain elements would be on the wire at the same time.
62
4. Design
Figure 4.9: Sender state machine for sending and receiving IHC-signed messages with pre-signatures and pre-acknowledgements. Packets with invalid or outdated hash chain elements are dropped if not mentioned explicitly. The receiver transitions to state TRIG sent when it receives a new PSIG packet which contains a valid hash chain element. State MSG sent In state MSG sent, the sender starts a timer and waits for a valid ACK packet. It retransmits the MSG packet without using a new hash chain element when the timer times out. This retransmission ensures that the signature process does not stall in case the MSG packet or the ACK packet from the receiver gets lost. TRIG packets with old hash chain elements are dropped in state MSG sent. The MSG packet is not retransmitted in case an old TRIG packet arrives. Packets are dropped because an attacker could potentially generate a storm of replayed TRIG packets to amplify an attack on the receiver. Details on this precaution are provided below. The sender does not buffer any PACK and PNACK values from old TRIG messages. This is a precaution to prevent replay attacks with old trigger values. An attacker could try to overwrite the buffered PACK and PNACK values with bogus data if the sender would buffer PACKs and PNACKs from old messages. Valid ACK packets must contain a valid hash chain element of the receiver’s trigger chain and either an acknowledgement or a negative acknowledgement secret. The sender verifies
4.2. LHIP Authentication Layer
63
Figure 4.10: Receiver state machine for sending and receiving IHC-signed messages with pre-signatures and pre-acknowledgements. Packets with invalid or outdated hash chain elements are dropped if not mentioned explicitly. the acknowledgement by comparing the buffered PACK and PNACK values with the result of formula 4.1.and 4.2. The PSIG and the TRIG packets must be retransmitted in case of a negative acknowledgement. The sender generates a new PSIG packet with the next undisclosed hash chain element of its signature chain. The sender recalculates the pre-signature with the next hash chain element, sends this new PSIG packet, and transitions to state PSIG sent. This backward step is necessary as the negative acknowledgement indicates that either the PSIG or the MSG packet has been modified by an attacker. The receiver was not able to verify the signature. In this case, the sender must retransmit both packets: PSIG and MSG. The use of a new hash chain element is necessary as the receiver has already seen the hash chain element and will consider it old or invalid. ACK packets with valid hash chain elements cause the sender to transition to state ready.
4.2.3.2
Receiver State Machine
The receiver’s authentication layer state machine consists of three states and six transitions. The state machine is depicted in figure 4.10. The receiver does not use any timers to retransmit packets. Retransmissions are always initiated by the sender. The receiver starts in state ready.
64
4. Design
State Ready The receiver drops all packets except valid PSIG packets in state ready. It verifies that the trigger value in a PSIG packet is valid and that it belongs to the sender’s signature hash chain. It sends a TRIG message which contains a new element of its trigger hash chain and the PACK and PNACK values. It stores the secrets which were used in order to generate the PACK and PNACK values. They are needed in order to send the acknowledgement later on. The receiver transitions to state TRIG sent after sending the TRIG packet. State TRIG sent In this state, the receiver waits for a valid MSG packet. It retransmits the previously sent TRIG packet without using a new hash chain element whenever it receives a PSIG packet with an old hash chain element. This is the case when the TRIG packet was lost due to transmission errors. The timer on the sender times out and it retransmits its old PSIG packet. The receiver generates a new TRIG packet with new PACK and PNACK values and uses a new hash chain element when it receives a new TRIG packet with a valid trigger value. This should not be the case during a successful signature process. The sender, however, could decide to abort the current signature process and to sign another packet instead. In this case, it sends another pre-signature after it received the TRIG packet from the receiver. The receiver drops all MSG packets as they must belong to previously finished signature processes. The receiver sends an ACK packet on receipt of a MSG packet which contains a valid hash chain element of the sender’s signature hash chain. This ACK packet also contains the secret acknowledgement value or the secret negative acknowledgement value which were used in order to generate the PACK and PNACK values. The ACK packet is interpreted as acknowledgement or negative acknowledgement depending on which secret is disclosed. The receiver transitions to state ACK sent after sending the ACK packet. The receiver delivers the message contained in the MSG packet to the HIP layer when it was verified successfully. The HIP layer can process the message without further authenticity verification as the authenticity was already verified by the authentication layer. State ACK Sent The receiver waits for incoming PSIG packets from the sender in state ACK sent. It retransmits the previous ACK packet whenever it receives a MSG packet with an old trigger value. This happens when the ACK packet gets lost on the way to the sender. The sender’s timer will time out and it retransmits the MSG packet with the old hash chain value. It is important to note that the receiver may not process the MSG packet any further as it is potentially replayed by an attacker. The receiver does not use any new hash chain values for the retransmission of the ACK packet. MSG packets with new hash chain elements are dropped as they can not be verified without a previously received pre-signature. This situation can be caused due to an attack. An attacker could have changed a PSIG to a MSG packet. Sending a new hash chain element in any response to the packet would create a serious state mismatch. The receiver, therefore, drops the packet and does not send any response. The receiver transitions to state TRIG sent if it receives a new PSIG packet, containing a valid hash chain element. This indicates that the sender has initiated a new IHC signature process.
4.2. LHIP Authentication Layer 4.2.3.3
65
Retransmissions
Retransmissions are necessary for two reasons. First, IP packets may get lost on their path or may arrive corrupted. This corruption is revealed by the checksum field, contained in the IP header. Erroneous packets are discarded and not processed. These packets must be retransmitted. Second, syntactically correct packets with valid checksum fields may carry invalid signatures. These invalid signatures are possibly caused by an attack. These errors require to start the signature process over. The LHIP authentication layer must react differently for both cases. Simple packet loss requires to retransmit the last packet without using a new hash chain element. These retransmissions are always initiated by the sender. Timeouts in the states PSIG sent and MSG sent are used in order to determine when packets need to be retransmitted. These retransmissions do not using new hash chain elements because no further hash chain elements have been disclosed after the packet was lost. Invalid signatures require restarting the signature process with a new PSIG packet which uses new hash chain elements. The invalidity of the signature is detected when the ACK packet is received. Either the PSIG or the MSG packet have been malicious. Therefore, both packets must be retransmitted. The old hash chain value of the first PSIG packet can not be reused as its preceding hash chain element was already disclosed in the MSG packet. As a consequence, the sender must use a new undisclosed hash chain element in order to start over the signature process. This means that each failed signature requires the use of two new hash chain elements on the sender side (for PSIG and MSG) and the use of two new hash chain elements on the receiver side (for the TRIG and ACK). Hash chains are finite. The initial seed value r is reached after a certain number of disclosed hash chain elements. A maximum number of retries retrymax for failed signatures must be defined since every failure consumes two hash chain elements. This limit is necessary to avoid that an MITM attacker can cause the hash chains to deplete. An error should be returned from the authentication layer to the HIP layer to indicate that safe message delivery is not possible. A multihomed LHIP hosts can try to send the message from another network device or to an alternative IP address of the remote peer. Thus, the IHC signature packets can possibly take another network path which is not controlled by the MITM attacker. 4.2.3.4
Duplicate Packets and Attack Amplification Prevention
Duplicate packets may occur due to protocol errors and replay attacks. The state machine handles duplicate packets in a way that ensures protocol functionality and prevents attackers from amplifying traffic for DoS attacks. Traffic can be amplified whenever the response to an incoming packet is considerably larger than the incoming packet. In our IHC signature approach, this is the case for TRIG and MSG packets. All other packet combinations do not yield an amplification ratio that is attractive to attackers. The TRIG packet is considerably smaller than the MSG packet which is sent as response to it. An attacker could try to use this imbalance to amplify its attack. The attacker could replay numerous TRIG packets which would lead to a storm of duplicate MSG packets. Thus, an attacker could use the sender of the MSG packet to amplify the attack. Our state machine prevents this attack. The sender will react to a TRIG packet only once. The sender ignores any further TRIG packets and uses a timer to determine when to retransmit the MSG packet. Therefore, it is impossible for an attacker to amplify an attack with a storm of TRIG packets.
66 4.2.3.5
4. Design Packet Serialization
The IHC signature protocol handles packets one by one. The cumulative transmission allows sending several pre-signatures within one PSIG packet and sending the MSG packets in parallel. The sender, however, can not send further packets before the signature process is completed. This requires serialization of packets. All packets are handed over to the authentication layer and are queued until it is possible to send them. This strict serialization is required to avoid that two related hash values are on the wire at the same time. 4.2.3.6
Undeliverable Packets
The IHC signature authentication layer is located below the HIP layer. The HIP layer generates its control messages and passes them with the source and destination IP addresses to the authentication layer. In some cases, this destination IP address may not be correct. This is the case when a host moves and it has not notified its peer about the change yet. This causes PSIG packets to be sent to an outdated IP address. The sender can recognize this situation by counting the number of PSIG retransmissions. Usually, undeliverable packets are handled by the HIP protocol. HIP may use an alternative network device or an alternative network address to deliver the packet. The authentication layer is unaware of these measures. The authentication layer can not send the PSIG packet from or to another interface as it is not involved in the locator management. The only thing that the authentication layer can do is to abort the signature process for a message and let the HIP protocol layer deal with the packet loss. An IHC signature cycle consists of four different packets. All of them can be undeliverable after a location change of the remote peer. We discuss the case in which one of the first two messages of the IHC signature, the PSIG or the TRIG message, are undeliverable. The case for MSG and ACK messages is analogous. Either the PSIG packet is lost on its way to the receiver or the TRIG message is lost on the way back. The sender can not distinguish these cases. We discuss these cases in the next paragraphs. In the first case the PSIG packet is lost. This packet contains hSi as trigger value and it is lost on the way to the receiver. The receiver expects hSi as trigger value and will not accept any other trigger values. The fact that the PSIG packet containing hSi was lost on its way to the receiver means that the receiver will accept any PSIG packet with hSi as trigger value. The receiver is unaware of the packet loss. In this case, the sender could just stop retransmitting the undeliverable PSIG packet and send hSi in another PSIG packet—with possibly different source and destination IP address. This mimics the behavior of normal packet loss. The second case is more complicated. The PSIG packet was already received by the receiver but the TRIG packet can not be delivered. The receiver has buffered the presignature and it will not accept other PSIG packets with hSi as trigger value. If it would, an attacker could just use the disclosed value hSi to make the receiver buffer bogus data. In this case, discarding the undeliverable PSIG packet, and sending another PSIG packet, using hSi will not work. The receiver would not accept this packet and the signature process of the second PSIG packet will fail. The sender has to use hSi−1 instead to place another pre-signature at the receiver side. The sender can not distinguish these two cases and, therefore, applying either is inappropriate and will cause the process to stall or will open security issues because two related
4.2. LHIP Authentication Layer
67
hash chain elements are on the wire at the same time. The solution for the second case is insecure, especially when the packet loss is caused by an attacker which delays or blocks packets. Our IHC signature state machine provides a way to deal with undeliverable packets without imposing security risks. Whenever a packet turns out to be undeliverable, the sender uses the same trigger value hSi to send the pre-signature of the next packet in the queue. The receiver accepts this pre-signature when the packet loss was caused on the way to the receiver. It will not accept the pre-signature if the packet loss occurred on the way back. It, nevertheless, sends a TRIG packet to indicate that it received the packet. The sender sends the MSG packet which contains the packet from the queue. In case the PSIG packet was undeliverable, the signature process will be successful because the receiver has accepted the new PSIG packet with the old hash chain value. In case the TRIG packet was undeliverable, the receiver has not accepted the new PSIG packet and it will use the pre-signature of the old PSIG packet to verify the signature. This is the case because the receiver has not buffered the second pre-signature which belongs to the current MSG packet. The receiver will send back a negative acknowledgement. The sender retransmits the PSIG packet with hSi−2 as trigger value. The remaining signature process will be successful. The sender should not count the failed signature as an attack in order to guarantee that retrymax retransmission attempts are performed for the packet. We propose using acknowledgements and retransmission of PSIG packets to solve the problem of undeliverable packets. The behavior of our authentication layer protocol exactly mimics HIP packet loss due to unreachable addresses. Thus, the HIP protocol can take appropriate measures to handle packet loss.
4.2.4
HIP Integration
The LHIP authentication layer is conceptually located below HIP. All HIP control packets are passed through the authentication layer. This layer determines whether a packet requires protection or not. This can be done by examining the parameters contained in the packets. Update packets containing new location information, new IPs, and new hash chain anchors need to be protected in order to avoid impersonation and connection disruption. Packets which require authentication are buffered and sent with the IHC signature scheme proposed earlier. The authentication layer on the remote peer verifies the hash chain signature and delivers the packet to the HIP protocol instance. In contrast to protected packets, unprotected packets are sent directly. They are not processed by the authentication layer. The authentication layer reuses the HIP packet format and the HIP parameter format to attach control information to HIP packets. This section describes the packets and parameters which are used by the authentication layer and the interaction with HIP HMAC signatures. 4.2.4.1
Pre-signature Creation
The LHIP authentication layer mimics the properties of the HMAC signature in the HIP packets. It should provide a similar kind of authentication and should cover the same part of the HIP packet. The HIP layer signs messages with the HMAC algorithm as it would without hash chain signatures. The authentication layer signs the contents of the HMAC
68
4. Design
parameter with IHC signatures. The HIP layer uses a fixed zero key for the HMAC creation because the hosts do not share a secret key. The HMAC is, therefore, not more than a message digest. Signing this message digest has the advantage that the HIP layer can still use all its mechanisms which build on the HMAC signature. Signing the message digest instead of the message does not reduce the security of the IHC signatures. Using message digests is very common for most signatures (see section 2.2.3). Using the HMAC signature as basis for IHC signatures has the advantage that HIP can still use the HMAC signature while the authentication layer is transparent to HIP. Thus, there is no need to replace the HMAC signature with other mechanisms to support IHC signatures. The authentication layer of the sender generates the pre-signature from the contents of the HMAC parameter and the next undisclosed hash chain element. It also uses the HMAC algorithm to generate the pre-signature using the following formula: psig = HM AC hSi−1 , HM AC(0 . . . 0, m)
(4.3)
The LHIP authentication layer on the receiving host verifies the IHC signature and passes the verified message to HIP. HIP can verify that the right portion of the message is covered by the HMAC signature and that the message digest is valid. It can verify the HMAC with the zero key. 4.2.4.2
Parameters
The LHIP authentication layer must exchange authentication data in order to provide its services. This data is transported in HIP packets and HIP parameters. We define several new parameters for use with the authentication layer. These parameters carry the trigger values, the hash chain anchors during the base exchange, the pre-signatures, and the acknowledgements. All of these parameters use the HIP TLV structure described in section 2.1.6.2. The selection of the parameter type numbers reflects the position of the parameter in the HIP packet: all parameters in the packet must be in ascending order. Parameters which are added after other parameters must have higher parameter numbers than those before. All parameter numbers of LHIP parameters are chosen from an appropriate type range. They have a preliminary character. Hash Chain Anchor Parameter The Hash Chain Anchor Parameter (HCAP) carries the anchor of a hash chain. These anchors are exchanged during the BEX. A message may carry several HCAPs. Besides the HIP parameter header, the HCAP contains an 8-bit anchor type field and a variable bit field for the anchor value. The 8-bit type field determines whether the variable bit field is an anchor for the signature chain, trigger chain, or some other hash chain. The HCAP is located in the parameter type range which is signed with RSA and HMAC signatures. It is used during the base exchange and within UPDATE messages. We use the reserved parameter type numbers and assign 1223. The odd number indicates that the parameter is critical. A host which does not understand this parameter must discard the message which contains the HCAP.
4.2. LHIP Authentication Layer
69
Hash Chain Value Parameter The hash chain value parameter (HCVP) carries the trigger values which are necessary for the IHC signature interactions. It is appended to all packets of the authentication layer. The parameter type number must be higher than any parameter type number used by the HIP peers because it is added after the HIP processing of the outgoing control messages. We decided on 64700 as the parameter number. It is also a critical parameter. Pre-signature Parameter The Pre-Signature Parameter (PSP) is used in the PSIG packet and contains the presignature of the message. It just consists of the HIP parameter header and a variable bit field for the hash function output. We chose parameter type number 64702 because the PSP is appended after the HCVP. This parameter is non critical because it may be contained in R1 and I1 messages (cf. chained bootstrapping in section 4.3.1.4). PACK, PNACK, HACK and HNACK Parameter The PACK and the PNACK parameters carry the PACK and the PNACK values. The Hash chain ACK (HACK) and the Hash chain NACK (HNACK) parameter carry the positive and negative acknowledgements in the ACK packet. These parameters just consist of variable length field which hold the secretack or secretnack hash value. The parameter numbers 64725, 64727, 64729, and 64731 are assigned to them as they are added after the HCVP. They are all critical. LHIP introduces some more parameters which are not directly used by the authentication layer. We will describe these parameters when they are used in this document. 4.2.4.3
Packet Types
The Authentication layer uses three new kinds of packets: the PSIG, TRIG and ACK packets. The MSG packet is the actual message with IHC signature parameters appended. Therefore, no special packet number is assigned for the MSG packet. The packet numbers assigned in this document are strictly preliminary. PSIG Packet The PSIG packet contains the HIP header, the hash chain trigger encoded as HCVP and the pre-signature encoded as PSP. We assign the packet type number 22 to the PSIG packet. TRIG Packet The TRIG packet contains the HIP header, a hash chain trigger in an HCVP and the PACK and PNACK parameters. We assign the packet type number 23 to it. MSG Packet The MSG packet is the HIP UPDATE packet which requires protection. The authentication layer adds a trigger encoded as HCVP to it. This trigger indicates that the packet is part of the signature process.
70
4. Design
ACK Packet The ACK packet also contains the HIP header and a hash chain trigger as HCVP. It either contains the HACK or the HNACK. The presence of a valid HACK indicates that the signature process was successful, while the presence of a valid HNACK indicates that the signature was invalid. The packet type number for the ACK packet is number 24.
4.3
LHIP Associations
The LHIP authentication layer provides protocol security for HIP. This section illustrates how both hosts establish an LHIP communication context and how LHIP ensures secure mobility updates. Other HIP specific protocol functionalities like closing an LHIP association require protection as well. We show how LHIP secures this functionality.
4.3.1
LHIP Base Exchange
HIP uses the BEX to create the HIP communication context, the so-called HIP association, on both hosts. Likewise, LHIP creates a communication context at the beginning of a communication. LHIP extends the HIP base exchange in order to establish the LHIP communication context. LHIP hosts generate the hash chains and exchanges the hash chain anchors with the remote peer during the base exchange. Unlike the HIP base exchange, no PK operations are performed during the LHIP base exchange. The LHIP base exchange is kept similar to the HIP base exchange to maintain compatibility with HIP and to enable hybrid LHIP and HIP implementations. It consists of the same four-way handshake as the HIP base exchange. All HIP specific fields except the RSA and HMAC signatures are present in the LHIP base exchange. LHIP does not change the semantics nor the functionality of HIP parameters like the puzzle, or the R1 generation counter. However, LHIP extends the functionality of the transform parameter and uses the new LHIP parameters during the BEX. 4.3.1.1
HIP Transforms
The fourth LHIP high-level goal is compatibility with HIP. Two LHIP-enabled HIP hosts need a way to agree on a HIP or LHIP association. This way should allow LHIP-enabled HIP hosts to communicate with pure HIP hosts by using HIP. A host which is not LHIPenabled should always establish a HIP association with LHIP hosts. The choice whether to use LHIP or HIP has to be negotiated during the HIP base exchange because the LHIP parameters must be exchanged during this stage. The first BEX packet, the I1 packet, is identical for both HIP and LHIP. The I1 only indicates that the initiator requests to establish either a HIP or an LHIP association. The type of the association is not determined yet. LHIP defines an LHIP transform suite ID. An LHIP-enabled responder can express its preference for LHIP by adding the LHIP transform suite ID to the HIP transform parameter in the R1 message (see section 2.1.4.2). This LHIP transform suite ID indicates that the responder supports LHIP for message authentication. The order of HIP transforms indicates whether the responder prefers LHIP or HIP. The absence of the LHIP transform suite indicates that the host does not support LHIP or that it is not willing to establish an LHIP association for the selected HI.
4.3. LHIP Associations
71
The initiator selects a HIP transform suite from the given transform suites and sends it back to the responder. LHIP will be used if the initiator selects the LHIP transform suite. An initiator which does not support LHIP will not select the LHIP transform suite and ignore it. Such an initiator will always use plain HIP associations. This way of agreeing on a HIP or LHIP selection maintains full compatibility between LHIP-enabled and normal HIP hosts. No additional packets or parameters are needed in order to agree on an LHIP association. 4.3.1.2
Hash Chain Anchors
The hosts must exchange all hash chain anchors during the base exchange. These anchors are added to the I2 message and the R2 message. This enables the responder to stay stateless until it receives the I2 message. Furthermore, this approach enables the responder to use pre-created R1 messages. Adding the initiator’s hash chain anchors to the I1 message would require that the responder establishes state after receiving the I1 message. The responder would have to store the anchors and, therefore, create state. This is not desirable as the HIP I1-R1 mechanism enables the responder to verify the routability of the initiator’s IP address before establishing state. Adding the hash chain anchors to the I1 message would make this stateless locator verification impossible. Consequently, we add the hash chain anchors to the I2 message. Adding the hash chain anchors of the responder to the R1 message would also mean that the responder can not pre-create the R1 message. Instead, it would be required to generate distinct hash chains for every R1 message. Using one pre-created message with only one set of hash chains is impossible because a hash chain must only be used for one LHIP association. Reusing a hash chain would render the IHC signature system insecure. Although, the hash chain creation is computationally inexpensive, computing new hash chains for every R1 message would enable attackers to attack LHIP hosts with a storm of I1 messages. Therefore, we decided to add the hash anchors to the R2 message. 4.3.1.3
RSA Signatures
The R1 message is the only message of the LHIP base exchange which must be signed with RSA for compatibility reasons with HIP. All other messages are not necessarily signed with RSA. As a consequence, hosts can not authenticate their peers. However, this is not a design goal for LHIP. This means that weak hosts do not need to calculate RSA signatures in most cases. Nevertheless, RSA signatures are necessary in case of namespace conflicts. Section 4.4.1 describes the possible attacks on LHIP and how RSA signatures are used in order to prevent these. 4.3.1.4
Hash Chain Signed Base Exchange
The four-way base exchange can not be protected by the authentication layer because the hash anchors are exchanged in the last initiator and in the last responder message. Using the authentication layer to sign these messages would require additional packets. Furthermore, it would not significantly increase the security because an MITM attacker could still replace the hash anchors which are exchanged during the base exchange. A way to gain increased security is to use chained bootstrapping in a similar way as WIMP does. Figure 4.11 illustrates the process. The hash chain anchors are denoted asig for the
72
4. Design
Figure 4.11: Chained bootstrapping for LHIP. The LHIP BEX is depicted in a simplified form. Both peers sign their BEX messages with IHC signatures. signature chain, atrig for the trigger chain and ax for further chains. The corresponding seed values are denoted ssig, strig and sx for further hash chain seeds. Recall that the hash chain is calculated from the seed values. The I1 can contain the pre-signature of the I2 packet. Placing the signature of the I2 packet in the I1 packet requires that the initiator computes both packets at the same time. Fields in the I2 packet which depend on values that are contained in the R1 message must be left out of the signature. These values are not known at this point. The responder buffers the pre-signature in the I1 packet and verifies the I2 message as soon as it arrives. The pre-signature of the I2 packet is created with the anchor value of the signature chain in the I2 message. The responder can verify the I2 message with the pre-signature from the I1 message and the anchors in the I2 message. The chained bootstrapping mechanism ties together the I1 and I2 message and protects the hash chain anchors in the I2 message from manipulations. However, an MITM attacker can still modify the pre-signature and the hash chain anchor in order to forge packets. Chained bootstrapping is also applicable to the R1 and the R2 message. The responder can add an HMAC signature, created with the anchor value of its signature chain, to the R1 message. This signature can contain the contents of the R1 message and the hash chain anchors in the R2 message. The initiator can verify the I1 message and the hash chain anchors after it has received the R2 message. This means that the initiator must react to the unverified R1 message in order to continue the BEX. Chaining the R1 and R2 message ensures that both messages have been sent by the same host and that neither the anchor values nor the contents of the R1 message have been modified. However, it is possible that an MITM attacker modifies both messages and forges R1 and R2 messages with different contents and anchor values. Chained bootstrapping requires the initiator and the responder to compute their hash chain anchors in the first step of the BEX. The responder must store the pre-signature of the I1 packet until the I2 message arrives. Furthermore, it must create and store the hash chains
4.3. LHIP Associations
73
used for the association before it sends the R1 message. It can either establish state or it can use the echo request field to store the values. In order to avoid state establishment after receiving the I1, it can create an encrypted envelope with a symmetric encryption algorithm like AES. This envelope contains the seed values of the hash chains and the pre-signature from the I1 packet. It sends this encrypted envelope to the initiator but keeps the encryption key secret. The initiator sends back the echo response in the I2 message. The responder can open the envelope and use the pre-signature to verify the I2 message. It uses the seed values to compute the same hash chains as the ones which were used for creating the signature in the R1 packet. This enables the receiver to stay stateless and still use IHC signatures for the BEX. Encrypting the seed values instead of the complete hash chains keeps the echo request parameter small. It enables the responder to encrypt only single hash values instead of whole hash chains. The hash chain can be calculated from the seed value later on. However, this technique requires the responder to calculate the hash chains twice: during the R1 and the R2 creation. Nevertheless, this is preferable to establishing state because the computation of short hash chains is computationally inexpensive. However, attackers can force the responder to generate hash chains for forged I1 packets 4.3.1.5
Diffie Hellman and RSA
The Diffie Hellman and the RSA HIs are exchanged during the LHIP base exchange. However, the Diffie Hellman shared secret is not calculated and the RSA identifier of the peer is not verified. These values are stored for later use during the upgrade process from LHIP to HIP. Hybrid LHIP- and HIP-enabled responders must sign the pre-created R1 message to maintain full HIP compatibility. However, this overhead is acceptable because only one signature is required for potentially many associations. 4.3.1.6
Pre-created Hash Chains
Hosts can speed up the connection establishment by pre-creating hash chains. Unlike the RSA signatures and the Diffie Hellman key exchange, there is no need to calculate the hash chains during the BEX. A host can pre-calculate a pool of hash chains. The host takes hash chains from the pool whenever it establishes a new association. The hosts refill their hash chain pools whenever they have CPU cycles to spare. 4.3.1.7
ESP NULL Encryption
Like HIP, LHIP also uses ESP to sustain the compatibility with HIP and HIP-aware middleboxes although the ESP traffic can not be encrypted securely due to the missing shared secret. LHIP hosts use the ESP NULL mode for packet encapsulation. This NULL mode neither encrypts nor authenticates the ESP packet but still performs all operations which are required to tunnel the payload to the destination host. A BEET association in ESP NULL mode is created during the LHIP base exchange. Similar to the normal BEET mode, the hosts must exchange the SPIs to set up the tunnel.
74 4.3.1.8
4. Design Concluding the LHIP Base Exchange
In the end of the LHIP base exchange, both hosts have agreed to use LHIP and both hosts have exchanged their hash chain anchors. An unencrypted ESP BEET tunnel is established and the hosts can exchange payloads via this tunnel. Both hosts are able to send authenticated UPDATE messages which an attacker—MITM or not—can not unnoticeably modify. Both hosts have stored the Diffie Hellman keys and HIs of their peer for later use. Neither of the hosts has computed RSA signatures, or done RSA signature verification, and the Diffie Hellman shared secret during the base exchange. This means that both hosts save one RSA signature, one RSA signature verification and one DH shared key computation.
4.3.2
Mobility and Multihoming Updates
LHIP uses the new authentication layer to protect mobility and multihoming updates. LHIP does not modify the basic update process nor does it replace the update messages with other packets. This maintains compatibility with HIP-aware middleboxes and allows us to reuse the HIP update functionality, including present and future extensions without modifications. The LHIP authentication layer protects the first pair of HIP UPDATE messages. The U1 and U2 messages need protection because they contain the new location information and the SPI values of the peers. Otherwise, an attacker can disrupt an LHIP association or reroute traffic if these messages are unprotected. Such an attacker does not necessarily have to be located on the communication path. Guessing the HIs, SPIs, and IP addresses of the peers would be sufficient to perform an attack. Therefore, these messages require authentication. Unprotected Third Update Message The third UPDATE message serves as response to the return routability test (see section 2.1.8). It contains an ack parameter and the echo response parameter. This message does not need protection. In order to show that this decision does not influence the security of LHIP we assume two kinds of attackers: eavesdroppers which are not on the communication path and MITM attackers on the communication path. We first analyze the case of an MITM attack. An MITM attacker can either drop or modify the message. An attacker can not modify the message without invalidating it because it only contains an acknowledgement and the echo response. The receiver can easily discover modifications of these parameters. Both actions, modification and destruction, therefore, lead to the same result: the path can not be verified. A signature can not protect against this attack because it can only identify the manipulation but not prevent it. An eavesdropper can send a forged packet with invalid contents but it can not drop the actual UPDATE packet. This means that an eavesdropper can possibly deliver a forged UPDATE message before the legitimate UPDATE packet reaches the host. However, the receiver can ignore invalid messages and wait for a packet with a valid echo response. It can use timeouts to mark a locator as unroutable if it receives no valid response within a certain time span.
4.3. LHIP Associations
75
Figure 4.12: The LHIP update process is protected by IHC signatures. The original update packets are marked with U1, U2, and U3. The U1 and U2 packets are the MSG packets of our IHC signature scheme. We decided not to protect the third message since a host will notice manipulations even without signatures. This saves three IHC signature packets which would be required to protect the message. 4.3.2.1 LHIP Update Process The three-way HIP update process is extended by the packets which are required for IHC signature authentication. Two full IHC signature authentication cycles are added for the packets which carry new locator information and ESP parameters. This makes the update process a nine-way update process. However, the ACK packet and the following packet are sent in parallel. This reduces the transmission time required for the update process to 3.5 RTTs. Figure 4.12 illustrates the process. Both hosts exchange UPDATE packets. These MSG packets, which are the U1 and U2 packets in the HIP update process, are preceded and trailed by IHC signature packets. The last UPDATE packet is unauthenticated. In contrast to HIP, no RSA signatures need to be calculated because the middleboxes can use the IHC signatures to authenticate the packets. Therefore, the LHIP update process reduces the computational overhead of HIP updates while it increases the communication overhead. 4.3.2.2 Updating Hash Chain Anchors Hash chains are finite sequences. This means that a host will run out of hash chain elements after using all hash chain elements. In this case, a new hash chain anchor must be transmitted to the host. This hash chain anchor must be signed to avoid identity theft during the lifetime of an LHIP association. LHIP uses UPDATE messages to exchange new hash chain anchors. The anchors can either be piggy-backed on UPDATE packets which are used in order to propagate new IP
76
4. Design
addresses or be sent in dedicated UPDATE packets. LHIP uses the IHC signature scheme to authenticate the packets which carry the anchors. A host which receives a new anchor from its peer stores the anchor and waits until its peer decides to use the new hash chain. A host does not explicitly announce that it starts to use the new hash chain. Instead it uses the first undisclosed hash chain element of the new chain. Its peer will notice that the HCVP parameter in the packet is invalid when it tries to verify it with the last known hash value of the peer’s old hash chain. In this case, it tries to verify the HCVP parameter with the newly announced anchor value. It continues to use the new hash chain values if the verification succeeds. This implicit way of hash chain activation requires no additional packets or parameters. The receiver calculates two hashes instead of one hash if the HCVP verification fails. This allows the hosts to send hash chain anchors to the peers at any time and to activate them anytime it becomes necessary. A host should place a new hash chain anchor before less than 2 · retrymax elements remain. retrymax is the number of maximum allowed restarts after negative acknowledgements during a hash chain signature process (see section 4.2.3.3). This ensures that there are always enough hash chain elements available to complete the signature process, even if it fails for retrymax − 1 times. The new hash chain may be activated at any time but it must be activated eventually when the old hash chain runs out of elements. A host decides how long the hash chains should be and when the hash chain should be replaced and activated based on local policies. Our IHC signature protocol design does not impose any restrictions on this choice, neither are both hosts required to use the same parameters.
4.3.3
LHIP Interaction with Middleboxes
HIP UPDATE messages are not only processed by the communicating peers but also by middleboxes on the communication path. These middleboxes learn about new IP addresses and SPI values by inspecting the UPDATE messages. HIP uses RSA signatures to sign these messages. This enables middleboxes to filter out forged messages which aim at disrupting a HIP association by modifying the state of the middlebox. As described in section 2.1.7, the middleboxes can not use the HMAC signatures for message verification because they are not in possession of the shared secret. IHC signatures do not rely on a shared secret. The middleboxes can use these signatures to verify HIP UPDATE messages without using costly PK operations. 4.3.3.1
Update Verification
A middlebox learns the update packet by observing the trigger values in the packets. Assume host A and host B have established an LHIP association. A middlebox M learns the hash chain anchors of both hosts during the base exchange or during the update process. It learns of the anchor value hA i+1 of the signature chain of host A and the anchor value hB of the trigger chain of host B. Host A sends an IHC signature protected UPDATE i+1 packet when it changes its position. M has to learn about the new IP address of host A during the update process. M observes the first PSIG packet from A to B. It contains the next undisclosed element hA i of the signature chain of A. It can verify this PSIG packet by A A comparing H(hi ) to hi+1 . It buffers the pre-signature and waits for the TRIG packet from host B.
4.3. LHIP Associations
77
Figure 4.13: Middleboxes learn the hash chain elements during the BEX and during updates. The TRIG packet from host B to host A indicates that host B has received the pre-signature. M can verify the origin of the TRIG packet with the HCVP parameter contained in it. Eventually, host A sends the MSG packet. This packet contains the new locator of host A and hA i−1 . The middlebox can verify the MSG packet and therefore, the authenticity of the new IP address and update its mapping between HITs and IP addresses accordingly 4.3.3.2
Middlebox State Update
Middleboxes learn of the hash chain elements during the BEX and during updates. Figure 4.13 illustrates the process. Host A and host B have established an LHIP association and exchanged their anchor values. Middlebox 1 stores these values in order to verify packets later on. Host A changes its location and sends an update from a new IP address. Middlebox 1 can verify the hash chain value in the PSIG packet. It stores the new hash chain values during the update process. Host A has moved behind Middlebox 1. This middlebox allows outgoing traffic from A and stores the hash chain values during the update process. It can verify PSIG messages from B whenever B moves to another location. Middleboxes must buffer the first message of the IHC signature until the message with the corresponding hash chain element arrives. The pre-signatures, proposed in section
78
4. Design
4.2.1.2, keep this first message small. This makes it easier for middleboxes to handle IHC signatures. The middlebox must let PSIG and TRIG packets pass through without verification of the source IP addresses contained in them. However, it should check that only a limited number of PSIG and TRIG packets are sent to the same IP address to avoid DoS attacks with these packets. It should also verify that the HCVP in the packets are either valid or old. Packets containing invalid HCVPs should not be forwarded. It should also check that these packets contain no payload besides the HCVP, the PSP, the PACK and the PNACK parameters and should drop packets which contain further parameters to prevent attacks. 4.3.3.3
Known Limitations
Our IHC signature authentication scheme for middleboxes enables LHIP hosts to send UPDATE messages without costly RSA signatures and relieves middleboxes of the task of verifying RSA signatures. It only requires to buffer small pre-signatures instead of the whole message. However, these middleboxes must support LHIP explicitly. HIP support is not sufficient in order to verify LHIP update messages.
4.3.4
Closing an LHIP Association
The HIP protocol uses CLOSE messages to indicate that a HIP association should be closed. Both hosts delete the state bound to the communication context and tear down the BEET tunnel. HIP CLOSE messages are protected by HMACs and RSA signatures. LHIP must naturally protect this message to avoid that an attacker can close the LHIP association with a forged CLOSE message. A naive approach would be to protect the closing procedure with IHC signatures. This would make the two-way close process an eight-way IHC-signed process. However, this is not necessary for CLOSE messages. CLOSE messages only transfer one piece of binary information. Either a host requires to close a HIP association or not. We can use an approach which is similar to Lamport’s one-time signatures to secure these messages. We exchange a short hash chain which only consists of the random seed value r and the anchor value h1 . This hash chain is called close chain. We call hash chains which only consist of two elements binary hash chains. The host publishes the anchor of this binary chain during the LHIP base exchange. It discloses the seed value r whenever it decides to close the LHIP connection. Its peer can verify the CLOSE message by comparing H(r) to the anchor of the close chain h1 . A host can be sure that its peer requests to close the HIP association if those values match. It sends back a CLOSE message containing an ack parameter and the seed of its own close chain. Thus, both hosts can verify that their peer is closing the LHIP association. This procedure does not require additional packets nor the use of RSA signatures. Middleboxes which have observed the BEX are also able to authenticate the close messages. However, middleboxes which have not observed the BEX can not do authentication for CLOSE messages. They have not learned the anchor of the close chain because the BEX packets were routed over a different communication path. They must use conventional approaches, e.g. timeouts for inactive associations, in order to determine when to delete the state allocated for the communicating peers. An alternative way to inform middleboxes about the anchor of the close chain is to include this anchor in the signed part of every UPDATE message. Accordingly, even middleboxes which have not observed the BEX are able to verify close messages.
4.4. Namespace Security
4.4
79
Namespace Security
The third high-level goal of LHIP is namespace security. We stated that it is not necessary for LHIP to authenticate hosts. The namespace must, nevertheless, be protected from malicious use. HIP verifies the authenticity of the HIs and, therefore, the RSA signatures during the BEX. LHIP reduces the computational overhead by omitting these checks. Section 4.4.1 will illustrate attacks on the HI namespace which are possible when host identifiers are not verified. Section 4.4.2 describes defenses against these attacks.
4.4.1
Attacks Without Namespace Protection
The attack vectors opened by the LHIP design presented so far can be used by an attacker for impersonation and DoS attacks. The attacks build on the fact that the HIs of LHIP hosts are not verified during the BEX. For the attack to work the attacker needs a priori knowledge of HIP associations before they are established. This knowledge can be gained by communication pattern analysis of victim hosts. The attacker must learn with which host the victim will establish an LHIP communication context before the BEX takes place. This a priori knowledge can be easily obtained by observing a host for a while since most hosts have a set of hosts that they regularly communicate with. E-mail communication, automated update services, instant messaging, or shared folders and printers are typical examples of frequent communication between the same hosts. 4.4.1.1
HI Blocking Attack
The HI blocking attack exploits the fact that HIP and LHIP use a pair of HIs to identify a HIP context. This means that only one HIP or LHIP association can exist for every pair of HIs. This situation does not lead to problems for plain HIP because only a host, which is in possession of the private keys, is able to establish a HIP association. The HI is statistically unique and collisions between HIs are expected to be extremely unlikely. In contrast to HIP, LHIP does not use RSA signatures to authenticate the identities of the hosts during the BEX. Therefore, every host can impersonate any other LHIP host. However, host authentication is not a goal of LHIP. An attacker exploits the fact that only one LHIP association can be assigned to a pair if host identifiers. It blocks connection attempts of a victim by establishing a HIP association with the victim’s HI before the legitimate does. There are two simple but insecure approaches to solve with this problem. Either the server denies its service for the first or the second peer whenever two hosts try to establish a HIP association, using the same HI. Either it prefers the existing association and denies its service to the second host. Alternatively, it prefers the new association establishment attempt and discards the association of the first host. Either way provides possibilities to mount a DoS attack. First, we assume that the server prefers the first LHIP association. An attacker establishes an LHIP context with a server by using the host identity of the victim. Consequently. the server denies the service for the victim when it connects to the server using its own HI. Second, we assume that the server prefers the new LHIP association and closes the older association. In this case, the attacker can disrupt any existing HIP association by establishing a new HIP association to the server with the victim’s HI. These examples show that attackers can misuse the unprotected HI namespace for attacks which surpass simple impersonation. These attacks are worse than today’s attacks on the IP or TCP protocol.
80
4. Design
The use of RSA signatures in case of conflicts prevents the attacks discussed above. For every I1 message in the BEX, the responder checks whether a HIP association exists which uses the HIs contained in the I1. If that is the case, the responder requires the initiator to sign its I2 message with its HI. If the signature is valid, the responder discards the existing LHIP or HIP association and establishes a new association with the initiator. Accordingly, legitimate hosts are protected from namespace attacks. Moreover, legitimate hosts can prove their identity to servers that have already established an association with an attacker. This policy does not introduce a performance overhead in the common case of legitimate communication because the use of RSA signatures is only necessary in the case of conflicts. The presented approach opens the following attack vector: attackers can try to provoke HI collisions and force a server to verify the HIs of spoofed I2 packets. However, when a server suspects that it is under attack, it is able to force the client to solve a cryptographic puzzle by utilizing the HIP puzzle mechanism. 4.4.1.2
HI Stealing Attack
An attacker with a priori knowledge of the peers which an LHIP host will connect to can mount a second kind of attack. The attacker exploits the fact that a host which has already established a HIP association with another host will reuse this association for all further communication between the hosts. An attacker A can impersonate a server S by using the server’s host identity HIS . The attacker can not impersonate the server in a global scope without influence on the name resolution infrastructure but it can spoof the HIT of the server and establish a LHIP association with a victim V . This circumstance is problematic when a process on the victim tries to open an LHIP association with S. The LHIP layer reuses the LHIP association with HIS and sends the packets to the attacker. This allows the attacker to circumvent the name resolution structure and to impersonate other hosts. This is problematic whenever the initiator assumes that the name resolution infrastructure is trustworthy. This attack is possible because the host neither checks HIs for incoming nor for outgoing traffic and because HIP uses one HIP association for all traffic between two hosts. Consequently, an attacker can open an LHIP association without proving its identity and circumvent the HI resolution infrastructure. Authenticating either the HIs of peers for outgoing or incoming requests for LHIP associations prevents this attack. A host which typically acts as client should authenticate the HIs of its peer whenever it acts as responder to prevent the HIT stealing attack. Consequently, a server should authenticate the HIs of its peers whenever it acts as initiator. This increases the computational overhead of LHIP. However, in most cases clients do not act as responders while servers typically do not act as initiators.Thus, clients use unauthenticated LHIP associations for outgoing traffic and servers use unauthenticated LHIP associations for incoming traffic.
4.4.2
Defense Mechanisms
The previous section shows that the HI namespace is vulnerable to attacks if host identifiers are used without verification. Conditional use of RSA for HI verification prevents these attacks. LHIP must provide a way for hosts which discover namespace conflicts to inform their peers that they must authenticate. We introduce mechanisms for conditional authentication and discuss security implications in the remainder of this section.
4.4. Namespace Security
81
LHIP Flags We introduce the LHIP flags parameter (LFP) which holds information about an LHIP association. It expresses whether a host requires authentication from its peer and whether it is willing to authenticate itself. During the BEX, the responder adds the LFP to the R1 message. It sets the authentication required flag when the initiator must authenticate. It sets the authentication granted flag when it is willing to authenticate to the other host. If requested, the initiator uses RSA to sign its I2 message in order to continue the LHIP base exchange. The initiator adds an LFP to the I2 message which indicates whether the responder should authenticate or not. The responder must prove its identity by using RSA to sign the R2 message if requested by the initiator. The BEX fails if a host which is required to authenticate is not willing to authenticate. In this case, opening an LHIP association is not possible. The initiator can determine this situation on receipt of the R1 and proceed with a regular HIP BEX alternatively. Attackers can exploit the conditional signatures to mount DoS attacks which are targeted at the CPU resources of a host. Therefore, a host may deny to use RSA according to its policies. It expresses this denial by setting the according bit in the LHIP flags parameter to 0. The LHIP flags are added to the R1 message after all other parameters because the parameter is appended to the pre-created R1 packet. We, therefore, assign 63404 as the parameter type number. The even number indicates that the parameter is not critical. We decided to use a non-critical parameter which implementations that do not support LHIP should ignore. Prevention of Replay Attacks RSA signatures are susceptible to replay attacks if the singed part of the message does not contain data which is unique for every message. An attacker can exploit this weakness by replaying such old LHIP I2 and R2 messages. The DH key exchange prevents such replay attacks for HIP. However, the DH shared key is not generated by LHIP hosts. The responder can not distinguish replayed LHIP I2 and R2 messages from legitimate messages if these messages do not contain unique data. Therefore it will discard the old HIP association and establish a new HIP association with the attacker. Including a unique echo request parameter in the R1 and I2 messages prevents this attack. On receipt of the signed echo response, the responder checks that no other LHIP association has been established with the same echo response before. The echo request parameter allows the responder to hide information in it. This supports the responder in verifying the uniqueness of the echo response. 4.4.2.1
Authenticated Hash Chains
The RSA signatures, which are used in order to authenticate a host, also cover the hash chain anchors of the host. Consequently, the hash chain is tied to the HI of a host. The hash chain can be used to authenticate the host later on. The peer and the middleboxes on the path can verify that updates and close messages were sent by an legitimate owner of an HI. This authenticated LHIP mode has the same namespace properties as HIP. The HI of the host can be authenticated without any unambiguously. It is not possible to impersonate the host, neither during the BEX nor during the lifetime of an LHIP association.
82
4.4.3
4. Design
State Loss
A host can lose all information about an established LHIP association due to events like hardware errors, software errors, program crashes or an operating system reboot. In this case, its peers still use the context information of the broken HIP association. Recovery from state loss is assisted by late authentication and occurs as follows. We assume that host A lost its state while host B still assumes that the LHIP association is valid. A tries to establish a new LHIP association by sending an I1 message to B. B receives the I1 message from B but it can not distinguish this situation from the previously described attack scenario (see section 4.4.1.1). Therefore B requires A to authenticate its identity in the I2 message by setting the corresponding flag in the LHIP flags parameter or the R1. Next, A receives the R1, checks the LHF parameter and consequently signs its I2 message. B checks the RSA signature of the I2 and establishes a new LHIP association with A if the signature is valid. It replaces the old LHIP association with the new one. This way of state loss recovery is exactly the behavior which was introduced above in order to prevent the HI blocking attack.
4.5
Association Upgrades: From LHIP to HIP
One design goal of LHIP is upgradability to HIP. An LHIP association should be transformable to an HIP association without the need to close and reestablish the association. In order to upgrade from LHIP to HIP, both hosts must calculate the shared secret, generate the necessary keys from it, verify their HIs and replace the NULL mode encrypted BEET tunnel with an encrypted BEET tunnel. Nearly all information which is needed to complete the upgrade is already exchanged during the BEX. This section describes which modifications to the BEX are necessary, how the upgrade is signalled, and how it is performed.
4.5.1
Second HIP Transform
The HIP transforms indicate which algorithms are used during a HIP association. The selected HIP transform defines the hash functions which are used for the HMAC algorithm as well as the symmetric key algorithms used for ESP encapsulation. The LHIP transform suite indicates that a host will use the lightweight authentication layer. The suite also determines which hash function should be used by the authentication layer. In HIP, the initiator of the base exchange selects one HIP transform suite from the selection of transform suites offered by the responder. In order to upgrade an LHIP association, both hosts must agree which transform suite to use after the upgrade. LHIP hosts use the transform parameter to agree on two choices: an LHIP transform suite and a HIP transform suite. An LHIP-enabled hosts which wants to use upgradable LHIP sends back the LHIP transform as the first choice and a HIP transform as second choice. Both hosts store the selected HIP transform and use it during the upgrade process.
4.5.2
Upgradable Associations
An LHIP association is upgradable only if both hosts have exchanged their DH parameters, the second HIP transform and an echo request parameter during the BEX. Furthermore, both hosts must be willing to upgrade the association depending on local policies. This
4.5. Association Upgrades: From LHIP to HIP
83
Figure 4.14: The LHIP upgrade process. A host has to add the echo response parameter and the RSA signature if it has not already authenticated itself during the LHIP base exchange. willingness is expressed by setting the upgradable flag in the LHIP flags parameter (see section 4.4.2). The connection is upgradable when all necessary parameters have been exchanged and both hosts express their willingness.
4.5.3
Upgrade Process
Upgrades are necessary if an application opens a socket, for example, and requires authentication and encryption for this socket. An existing LHIP association with the socket’s destination host can be updated in that case. Another case is that local policies or a change of location might cause an application to require increased security. The upgrade process is a two-way message exchange. We use HIP UPDATE messages to carry the upgrade information. We refer to these UPDATE messages as UPGRADE messages though we do not define a new message type for these. We refer to the host which initiates the upgrade process as initiator and its peer as responder. These should not be confused with the initiator and responder in the BEX. Figure 4.14 illustrates the upgrade process. LHIP uses RSA and DSA signatures during the UPGRADE process. The two-way upgrade process is not protected by client puzzles. Attackers could open numerous LHIP associations and upgrade them at the same time in order to put heavy load on the responder. It is an open question how such DoS attacks can be prevented. Exchanging a fresh puzzle before the upgrade would require two additional messages which would slow down the upgrade process. Using the puzzles from the BEX gives the attacker enough time to compute the puzzles before performing the attack. However, hosts can use the LHIP flags to state that they are not supporting the LHIP upgrade process. In this case, the upgrade process consists of establishing a new HIP association through a standard HIP BEX. 4.5.3.1
First Upgrade Message
Before initiating an upgrade, the initiator calculates the DH shared secret based solely on the DH keys exchanged during the BEX. It generates the necessary symmetric keys and the keys for the HMAC creation from this shared secret. It sets up new IPsec SPs which use the algorithms selected in the second HIP transform. It also sets up a new outgoing IPsec security association with the symmetric keys.
84
4. Design
The initiator prepares an UPGRADE message which contains the SPI value of the new IPsec SA and adds an HMAC to protect the SPI values by using the freshly created key. The host must use its private RSA key to prove its identity if it did not prove its identity during the BEX. In this case, it includes the echo response from the BEX before the HMAC and the RSA signatures are applied. 4.5.3.2
The Role of Echo Response
The echo response protects the UPGRADE progress from replay attacks (see section 4.4.2). It ensures that the RSA signature was created for the current LHIP association and that the UPGRADE message is not a replay of a former LHIP UPGRADE exchange. Accordingly, the responder can verify that the initiator is in possession of the secret corresponding to the HI. 4.5.3.3
Role of the HMAC, RSA Signature Ordering
The fact that the HMAC signature is included in the RSA signature prevents the following kind of attack. We assume that the HMAC was added after the RSA signature and it would not be part of the signature to illustrate this attack. An MITM attacker replaces the DH parameter during the base exchange. Neither the initiator nor the responder notice this modification because the DH parameter is not protected by signatures. During the LHIP upgrade, the initiator signs the upgrade message and appends the HMAC signature. The MITM attacker then replaces this HMAC signature with the HMAC signature generated with its own DH shared key. The responder would use the attacker’s DH shared key to calculate the shared secret and would verify the RSA signature and the HMAC. Consequently, the responder accepts the packets of the attacker instead of the initiator as authentic. The order of the HMAC signature and the RSA signature prevents this kind of identity theft. The HMAC signature is included in the RSA signature and can not be replaced by an attacker unnoticed. This ties the HMAC and, therefore, the HMAC key, and, consequently, the DH public key of the initiator to the initiator’s HI. 4.5.3.4
Protection of the First Upgrade Message
The UPGRADE message triggers the DH shared key calculation at responder. This operation is CPU-intensive and can be used in an attack to provoke the DH calculations with a forged message. Similar to the HIP CLOSE message, the UPGRADE message only triggers the update and does not contain any explicit information which is not protected by the HMAC. Therefore, it is sufficient to use the same protection mechanism as for CLOSE messages (see Section 4.3.4). Both peers exchange the hash chain anchor of a binary hash chain, the upgrade chain, during the BEX. The disclosure of the next hash chain element of this hash chain indicates that a host has initiated the LHIP upgrade process. The disclosed upgrade chain element is attached as HCVP. The responder first checks the HCVP parameter in the message. It hashes it and compares it to the anchor value of the upgrade chain. This comparison is inexpensive and proves that the legitimate peer initiated the upgrade process. It calculates the DH shared secret if the hash chain verification is successful. The responder generates the symmetric keys and the key for the HMAC signatures from the shared secrets.
4.5. Association Upgrades: From LHIP to HIP
85
The responder can verify the HMAC signature in the UPGRADE message by using the freshly calculated keys. The responder modifies the IPsec SPs in order to use the encryption algorithms selected in the second HIP transform. It then sets up the outgoing and incoming IPsec SAs corresponding to the remote peer’s SPI and the symmetric keys. It is necessary to include the HIs of the peers in the UPGRADE messages to support HIP-aware middleboxes. The HIs in the packets enable these middleboxes to learn the public keys of the hosts, in case the middlebox has not observed the BEX. This is the case if one of the hosts has moved behind the middlebox during the LHIP association. 4.5.3.5
Concluding the Upgrade
The responder sends back an HMAC-protected UPDATE message which contains its SPI value for the incoming IPsec SA. The responder must authenticate, using its RSA or DSA private key, if it has not authenticated during the LHIP BEX. It must also include the echo response from the LHIP BEX to avoid replay attacks. The initiator can use the HMAC to verify the UPDATE message. It sets up its outgoing SA with the SPI given by the remote peer. At this point, both peers have upgraded to HIP and established an encrypted BEET tunnel. They do not use the LHIP authentication layer any more. The LHIP upgrade only requires two messages. The DH shared secret and the RSA signatures may be pre-calculated by a host in order to speed up the upgrade process. In this case, the upgrade is inexpensive and can be executed with little computational overhead. The first and the second UPGRADE packets are symmetric. This prevents problems when both hosts decide to send an UPGRADE packet at the same time. The fact that both UPGRADE packets contain identical parameters solves this problem. Each host will take the UPGRADE packet of its peer as reply to its own packet. Therefore, no additional measures are necessary to cope with simultaneously sent UPGRADE packets. 4.5.3.6
HIP Downgrade
A downgrade from HIP to LHIP is not desirable because both hosts are already in possession of the shared secret which enables efficient message authentication and symmetric encryption. The computational cost of an established HIP association could, nevertheless, be lowered by using NULL encryption instead of symmetric encryption for HIP. The runtime modification of a HIP association is out of scope for LHIP. However, the hash-chain-based update process might be of interest for middleboxes and weak hosts because of its low computational overhead. Such a mixed HIP and LHIP mode is future work.
86
4. Design
5. Implementation Our implementation of LHIP is based on the HIP for Linux (HIPL) implementation. The HIPL implementation supports most features provided by HIP. HIPL was first developed for use in kernel space and was moved to the user space later on1 . Moving HIP from kernel space required rebuilding some parts of HIP. This rebuild process was not complete when we started to work on LHIP. Especially the socket interface for HIP-aware applications was missing. HIPL consists of four main parts. The HIP daemon (hipd), the HIP socket handler (hipsock), the HIP configuration tool (hipconf), and the BEET extensions for IPsec. LHIP required changes to the hipd, hipsock, and hipconf tools. The BEET extensions which handle the IPsec BEET mode were not touched. The HIP daemon is a background process which handles most of HIPs functionality and is located in user space. The hipd is the HIP protocol instance on the host. It contains the state of all active HIP associations on the host and provides functionality to establish and maintain this state. The hipd communicates with other HIP instances over the raw socket interface. It opens a raw socket and registers as protocol 253, which is the preliminary protocol number of the HIP protocol. It sends and receives IP packets over this raw socket. These IP packets carry the HIP control messages. The HIP daemon uses sockets with address space AF_UNIX for local inter-process communication with hipconf and the socket handler. Hipconf is a configuration tool in user space and offers a command line interface. Users and applications can use it to give directives to the HIP daemon and to gather information about HIP associations. The command line language of hipconf is human-readable. Simple human-readable inputs modify the state of the hipd. The hipconf is the preferred tool to set parameters for all or certain HIP associations manually. 1 The HIPL implementation was first located in kernel space because the address translation between HITs and IP addresses in the kernel was performed by HIP. The BEET IPsec ESP mode allowed to utilize IPsec for this task. With the BEET mode it was possible to move the HIP protocol instance from kernel space to user space in order to make the deployment of HIP easier.
88
5. Implementation
Figure 5.1: The HIPL architecture and the communication between the components. Payload channels are not depicted. The HIP socket handler provides a socket interface for HIP-aware applications. It enables them to use HIP-specific socket options. It provides an API for applications. This socket API resembles the well known TCP and UDP socket API. It provides system calls to open, close, and to send data over a socket. The hipsock socket handler provides support for TCP and UDP sockets over HIP. The hipd, as well as the hipconf tool and the hipsock kernel module are written in C. The hipconf tool and the hipd use the user space C libraries, while the hipsock kernel module can only use the kernel C functionality. Hipd also uses external libraries, such as the openssl library for cryptography-related functions. Figure 5.1 shows how the HIPL components interact. Applications can either use the socket API or the hipconf tool to interact with hipd. Users can interact with the hipd over the command line interface of hipconf. Hipconf and hipsock use Unix local domain sockets to exchange information.
5.1
The HIP Daemon
The HIP daemon handles all HIP control messages. It opens, maintains, and closes HIP associations. The HIP daemon is conceptually and practically divided into different parts.
5.1. The HIP Daemon
89
These parts reflect the different states ranging from establishing to updating and closing a HIP association.
5.1.1
Packet Handlers
Figure 5.2 shows the packet handler functions of the hipd. Incoming control messages are handed over to the packet-handling functions by a dispatcher function. The packet-handling functions process packets and call other functions which generate new HIP control packets and which modify the state of a HIP association. These functions belong to four different function groups – the packet handlers.
Figure 5.2: The HIPL packet-handling functions. Blue components were modified for our implementation of LHIP.
90
5. Implementation • The BEX packet handler handles the base exchange packets. It generates and processes the initiator and responder packets. The state of a HIP association is created by these functions. • The update handler functions handle all update-related packets. This set of functions sends and processes update packets and modifies the HIP state and the IPsec associations. • The close handler processes and creates packets which are related to the tear-down of HIP associations. • The packet-handling for internal messages from hipsock and hipconf are contained in the internal packet handler.
The packet handlers use several support functions. These support functions provide services like HMAC verification, HIP parameter creation, or access to the state variables of a HIP association. The support functions are included in the hiptool library. 5.1.1.1 Modifications and Extensions to Packet Handlers We extended the functionality of the hipd packet handlers in order to enable LHIP support with HIPL and the hipd. Most of the extensions are contained in an LHIP function library and an LHIP parameter-handling library. The LHIP function library contains all functions related to the LHIP state establishment and the IHC signatures. It contains accessor functions to modify the state of an LHIP association, as well as functions for handling the IHC signatures. The LHIP parameter handling function library contains functionality which is required to create the LHIP-specific parameters and to append them to the HIP messages. It also provides functionality to read the LHIP parameters from HIP control parameters. Modifications of the BEX Packet Hander The BEX functionality was extended in order to exchange the additional LHIP parameters like the hash chain anchors and LHIP flags. The functionality of HIP was modified, too. The DH shared secret, for example, is not created during the BEX. The DH parameters are stored for later use instead. The RSA signatures are optional in LHIP. Therefore, we modified the basic BEX behavior. The hipd first checks if the peer requests authentication. It signs its next BEX packet and includes the echo response if its local policies allow authentication. Some UPDATE messages are protected by IHC signatures. Therefore, we extended the functionality of the update message handler. The IHC-signature-protected UPDATE messages are verified by the LHIP authentication functions. As hash chain anchors are carried in UPDATE messages, we modified the update handler in order to support the hash chain extension. The close packet handler was modified in order to authenticate CLOSE messages with hash chain elements. The handler adds hash chain elements to LHIP close messages and verifies incoming close messages which belong to LHIP associations.
5.1. The HIP Daemon
91
The handling of internal messages was also extended. The hipd, hipsock, and hipconf can exchange LHIP-related information with each other in order to modify the LHIP state. We introduced two additional classes of packet handler functions. The upgrade packet handler functions create and process LHIP upgrade packets. They verify the hash element and transform the LHIP state, including the IPsec settings, to HIP. They handle all aspects of the two-way upgrade packet exchange including the creation of the DH shared secret and the verification of RSA signatures. The authentication packet handler handles all IHC-related packets. It creates and processes the PSIG, TRIG, and ACK packets as described in the LHIP protocol proposal. These functions conceptually belong to the LHIP authentication layer.
5.1.2
State Centric Design
HIP associations are represented in the HIP Association DataBase (HADB). Every HADB entry represents one HIP association. The HADB identifies the entries by the HITs of the peers. An HADB entry contains all information of the HIP context. For instance, it stores the state of the HIP state machines, the IP addresses of both hosts and the symmetric keys. The HADB, therefore, contains the state of a HIP association. The first task during the LHIP implementation was to find a clean way to integrate HIP and LHIP. The LHIP authentication layer was designed to be mostly independent of HIP. However, other parts of the hipd were also modified. The symmetric keys, for example, are not generated from the DH shared secret any more as the shared secret is not created during the LHIP base exchange. Instead the DH parameters are stored and a zero key is used. Doing all these changes within the HIP code would make the HIP code more difficult to maintain and would unnecessarily increase the complexity of the hipd. Therefore, we added support for HIP extensions by replacing hard-coded function calls with pointers. These function pointers are contained in sets. Each HIP extension can define its own set of function pointers. The LHIP extension, for example, defines a set of functions and function pointers to them. The signatures of these functions are identical to the functions used in HIP. However, their side effects differ. The HIP function pointer set, for example, contains the function hip_csum_send. This function calculates the checksum for a given HIP message and sends it to the network. LHIP replaces this function pointer with lhip_csum_send. This function takes the same arguments and gives back the same return value. However, it buffers the message and initiates the IHC signature process when the message contents require protection. The choice, which function pointers should be used, is determined dynamically during the BEX. Each HIP association may use a different set of function pointers. LHIP associations use the LHIP function pointer set while HIP associations use the default function pointer set. The state of each HIP association defines how packets for this certain association should be handled. The function pointer sets modify the behavior of LHIP for packet transmission, packet-handling and packet protection. The dynamic selection of the function pointer sets enables our LHIP implementation to handle LHIP and HIP associations at the same time. Function pointers, therefore, support simultaneous associations with LHIP-enabled hosts as well as with pure HIP hosts. The inclusion of LHIP code in HIPL is controlled via a preprocessor macro.
92
5.1.3
5. Implementation
LHIP State
Similar to HIP, LHIP stores all data which is related to an association in the HADB. The HADB is extended by several additional fields which are required by LHIP to establish, maintain, upgrade, and close an LHIP association. The HADB for LHIP contains the pointers to the hash chains which are used by the peer. It contains the signature, trigger, close and upgrade chain. Furthermore, it stores pointers to recently exchanged signature and trigger chains which have not been initialized yet. The HADB also stores the last valid hash chain elements the peer has used. These values are updated every time a packet with a valid hash chain element arrives. After the BEX, these fields contain the hash chain anchors of a peer. Fields for new anchors of the peer are also present. The HADB also stores PSIG, the PACK, and the PNACK field for the receiver. They are needed to verify signatures and acknowledgements. All values which are required to upgrade the LHIP to a HIP association are also present in the HADB.
5.1.4
Authentication Layer
The HIP authentication layer is part of the hipd. The authentication layer touches the HIP code at two points. When messages are sent and when IHC signed messages arrive. The authentication layer sends the preceeding and trailing IHC signature messages and handles packet loss and transmission errors. It receives outgoing control packets from the HIP daemon via the function call lhip_csum_send. This function buffers the actual message and the source and destination IP address in a message queue and initiates the IHC signature. It sends the PSIG packet using the hip_csum_send function. The signature process is transparent for the HIP protocol part of the hipd. The authentication layer extends the hipd update handler in order to receive incoming update packets which are protected by IHC signatures. These packets are verified by the authentication layer functions before they are processed by the update handler of hipd. The authentication layer uses the information which was transmitted in previous PSIG packets to verify the messages. Erroneous packets are dropped by the authentication layer functions. The authentication layer sends acknowledgements and negative acknowledgements depending on the validity of the packet. Incoming acknowledgement packets cause the authentication layer to either retransmit the PSIG message or to continue with the next HIP control message in the queue. 5.1.4.1
Message Queue
All messages which are passed to the LHIP authentication layer are buffered in the LHIP message queue. This queue is a First In First Out (FIFO) buffer. It enqueues all packets which require IHC signature protection. Furthermore, it ensures the strict serialization which is required by the IHC signature scheme. The queue is periodically checked for necessary retransmissions. Packet loss is handled as specified in our state machine (see Section 4.2.3.1). A maintenance process determines whether retransmissions are necessary or not.
5.1. The HIP Daemon
5.1.5
93
State Machine
We implemented both the sender and the receiver state machine. The different state transitions are triggered during the packet-handling process. PSIG, TRIG, and ACK packets are handled by the authentication layer functions alone, while MSG packets are handled by the authentication layer and the HIP update handler.
5.1.6
Hash Chains
Hash chains are the central element of the LHIP protocol. We created a hash chain library which covers all functionality required to build and manage hash chains. The functionality of the hash chain library consists of functions for hash chain creation, verification, element access, and hash chain destruction. The hashes for the hash chain are stored in a chained list. The hash chain header contains information about the length and the element which is currently in use. We used hash chain lengths of 20 elements per non-binary chain for our tests. We use a maximum retransmission limit of 5 retries in case of failed signatures (see 4.2.3.3). This means that ten mobility updates are possible in the best case and at least two mobility updates can be signed in case of an attack. We assume that this is sufficient for most mobile hosts. Our LHIP implementation supports hash chain extension to support an effectively unlimited number of mobility updates. 5.1.6.1
Management of Hash Chains
Our LHIP implementation supports pre-created hash chains. A hash chain manager precreates hash chains of different length. It periodically pre-creates hash chains until a maximum number of hash chains is reached. The pre-creation process is started only when no HIP packets are waiting to be processed. The HIP daemon takes hash chains from this pool during the BEX and whenever a hash chain must be replaced. The hash chain manager provides hash chains of different lengths. LHIP requires two different lengths: normal hash chains and binary hash chains. The creation of a SHA-1 hash chain with 20 elements takes 0.5 ms on the webpad and 0.03 ms on the Xeon server. For such short hash chains, the benefit of pre-created hash chains is marginal. However, even weaker devices or application scenarios, which require long hash chains, will profit from stored long hash chains. Pre-created hash chains allow hash chain computations to be performed when the CPU is idle. It is only necessary to create new hash chains during the BEX or during the hash chain extension process if no pre-created hash chains are available. 5.1.6.2
Extensions of Hash Chains
Hash chain anchors can be piggybacked on UPDATE messages. However, our implementation does not piggyback new hash chain anchors in order to extend the hash chains. This is due to the fact that the hash chain anchors must be covered by the HMAC contained in the message. HIP generates this HMAC value before it hands over the UPDATE message to the LHIP authentication layer. Therefore, the packet must be rewritten in order to place the anchors within the part of the packet which is covered by the HMAC. Alternatively, we could have added the anchors before the HMAC was applied. This would have required a tighter coupling between authentication layer and the hipd. Other
94
5. Implementation
implementations which will be integrated more closely, however, may be able to send piggybacked hash chain anchors efficiently . We send hash chain anchor updates preferably after updates. We assume that the locators are stable for several seconds, after a location update. We use the preferred IP addresses of the hosts to send the anchor updates. Anchor updates are only sent when no location update packets are queued. We use this restriction in order to avoid that anchor updates are sent to outdated IP addresses. The new hash chains are initiated when the last hash chain runs out of elements. Our implementation, therefore, uses hash chain elements efficiently and does not waste hash chain elements during the hash chain initiation.
5.1.7
Modifications of the Base Exchange
We modified and extended the functionality that the hipd provides during the BEX. Some of these changes also improved the HIPL implementation and are not only beneficial for LHIP. 5.1.7.1
R1 Generation Counter and Echo Request
The base exchange was extended in order to support LHIP. The hipd base exchange did not support R1 creation with echo request and R1 counter packets. However, these packets are required for RSA authentication in LHIP. We implemented pseudo-unique echo requests. The echo requests are required to mitigate replay attacks as discussed in section 4.4.2. These echo request are hashes of a secret, the R1 counter value, and the locators and HITs of both peers. The use of IP addresses and HITs guarantees that the echo response is only valid for associations with the same network and host identifiers. The presence of the R1 counter restricts the lifetime of the echo response. The secret ensures that attackers can not forge the echo response. The responder can easily verify the pseudo-unique value in the I2. The value is unique for all I1 and I2 packets from the same IP address with the same HIs which are generated during the same R1 generation period. The default R1 generation lifetime for the HIPL implementation is 60 seconds. However, setting shorter values is possible. A host first checks if the echo response is valid by creating the hash of the IP addresses, HIs, and the R1 counter value, and the secret. Then, it compares it with the echo response in order to verify that it is valid. Replay attacks with RSA-signed I2 packets are only possible within the lifetime of the R1 generation counter value after the LHIP association was established. To avoid immediate replay attacks, we only allow one HIP association to be established with the same echo response value. Established HIP associations can only be changed with differing echo response values.
5.1.8
NULL Encryption and the Missing Shared Secret
LHIP does not create a shared secret during the BEX. Consequently we replaced the shared secret with a zero byte string. The LHIP authentication layer protects all protocol functions which require signatures. Therefore, hipd works with the zero string as if it were a shared secret. All parameters which are necessary to generate the shared secret are stored to the HADB. They are used to upgrade the HIP association.
5.2. Hipconf Tool 5.1.8.1
95
Optional RSA Verification
LHIP supports the optional RSA signatures as proposed in section 4.4.2. The hipd verifies these signatures according to the procedure of the proposed LHIP protocol design. Moreover, the hosts can specify local policies which enable them to request RSA authentication for incoming, outgoing or both associations.
5.2
Hipconf Tool
The hipconf tool offers a command line interface for the HIP daemon. This tool accepts commands in a human-readable form, parses them and sends them to the hipd. We extended the hipconf tool in order to reflect the capabilities of LHIP. Via the hipconf tool, a user can instruct the hipd to upgrade a certain LHIP association. The association is identified by the HITs of both communicating peers. It is also possible to upgrade all established LHIP associations at once. The hipconf tool sends the upgrade request to the hipd. The hipd upgrades these associations if they are upgradable (see section 4.5.2).
5.3
Socket Handler
The HIP socket handler provides the socket interface for HIP-aware applications. This interface enables direct communication between the HIP daemon and the application. The HIP socket interface was inoperable after hipd had been moved to the user space. Therefore, we implemented a new socket handler reusing large amounts of code from the previous kernel space implementation.We implemented the socket handler as a loadable kernel module for modularity and reduced dependencies. The use of the hipsock interface requires registering the HIP protocol family in the kernel. Thus, all applications can use the protocol family AF_HIP in order to create HIP sockets. The socket calls are handled by the kernel module. For LHIP, the kernel module provides mainly the upgrade functionality Like the hipconf tool, the kernel module communicates with the hipd by using Unix local domain sockets of the address family AF_UNIX. We decided to also use the HIP packet format for the hipsock kernel module. This simplifies the packet-handling at the hipd and provides a consistent data transfer format. We implemented a bidirectional communication channel between the hipd and the socket handler. The socket handler can send commands to the hipd and can request information about the corresponding LHIP association from the hipd.
5.4
State of the LHIP Implementation
Apart from the optional cumulative packet transmission described in our IHC signature protocol (see section 4.2.1.2) and the chained bootrstrapping process (see section 4.3.1.4), all features of LHIP are implemented. The absence of the cumulative transmissions implies no practical limitation because it is an optional performance optimization for large numbers of concurrent updates. The implementation and evaluation of the chained bootstrapping process are future work.
96
5. Implementation
The interface of the hipsock socket handler is not completed yet. It supports the basic functions for establishing, using, and upgrading an LHIP association. However, it is not possible for a host to open a HIP association to a host with which it already has established an LHIP association. Improvements on the implementation of the socket interface and the interaction with applications are also future work.
6. Evaluation and Discussion In this chapter, we analyze and discuss the results of our work. The main goal of this work is to reduce the computational cost of HIP in order to make HIP applicable to weak devices. This chapter is divided into two sections. We present the performance evaluation of the LHIP protocol in section 6.1 and in section 6.2 we discuss to what extent the design and implementation described in the previous two chapters meet the high-level goals we envisioned in section 3.4.1.
6.1
Performance Evaluation
The first LHIP high-level goal is to increase the performance of HIP on weak devices. Therefore, we measured the performance of our LHIP implementation to evaluate how successful we were in achieving this goal. We observed the performance which HIP and LHIP achieve during the BEX, the update process, the closing procedure, and the LHIP upgrade process and present the results in the following sections.
6.1.1
Test Setup
We used the HIPL implementation and our LHIP-enabled HIPL implementation to compare the performance of HIP with the performance of LHIP. We measured the time consumed by relevant processes in the hipd. We mainly focused on the packet handling and cryptographic functions. The measurements show how much time is spent on processing the four main HIP or LHIP functions: the base exchange, the update process, the closing process and the LHIP upgrade. We prepared the HIP and the LHIP implementations with measurement functions in order to determine the duration of certain processes on the test systems. The time measurement functions separate the process of time measurement from saving the results in order to reduce the impact of the time measurement functions on the results. Where possible, data is saved while no measurements are in progress. We measured on the same systems which we used for the performance measurement of the cryptographic functions (see section 3.1.1). In practice, the N770 typically acts as client and, therefore, we used the N770 as initiator in our tests. We repeated the tests with the 3.2
98
6. Evaluation and Discussion
GHz Xeon to provide a basis for comparisons. A 3.0 GHz Xeon server acted as responder in all measurements. We used the gettimeofday function in order to measure time spans. This function has a resolution of 3 µs on the Xeon server and 30 µs on the N770. This resolution is sufficient in order to measure the processes in the hipd. Network Properties The Xeon computers were connected with a wired gigabit network. The N770 was connected to the Xeon server via an 802.11/b Wi-Fi network. We used the ping6 tool in order to determine the average RTT before and after the test runs. The given RTT values are the arithmetic mean value of 400 samples. The mean RTT between the Xeon hosts was 0.11 ms with a standard deviation of 0.01 ms. The mean RTT of the wireless link varied from test to test between 2.0 ms and 3.1 ms. The ping samples ranged from 1.6 ms to 22 ms. The standard deviation of the measurement with 3.1 ms RTT, for example, was 2.6 ms (83%) on the wireless link. All measurements that include packet transmission over the wireless link are, therefore, less precise and show a higher variance than the measurements which only include operations on the hosts. Very short RTTs, such as the RTTs in our test networks, are not typical for the Internet. They can only be achieved in small networks. Typical RTTs range from short RTTs such as 30 ms or less to long RTTs of 300 ms and more, depending on the location of the communication peer. Those results which include transmissions are therefore only valid in small networks. However, the results can easily be transfered to scenarios with higher RTTs in order to represent other network conditions. We will give additional examples with higher RTTs when appropriate. Results for higher RTTs can easily be extrapolated from our results. We did not measure with real Internet RTT as the variance of these RTTs would have made precise measurements and valid statements about the HIP and LHIP performance impossible. The results for the packet handling functions and the cryptographic operations do not depend on the RTT and are, therefore, valid for wide area networks as well.
6.1.2
Test Procedure
We used the following simple test schedule for our measurement runs. The initiator repeatedly establishes a HIP or LHIP association and add new IPv6 address to the initiator’s network interface after a short delay. The hipd notices this change and consequently initiated an update process. After the update process, the initiator closes the HIP or LHIP association. The presented performance values are the mean values of 200 test runs each if not mentioned otherwise.
6.1.3
HIP and LHIP Base Exchange
We first present our time measurements for the HIP and LHIP base exchange and its individual operations. We use RSA HITs of 1536 bits for the N770 and 1024-bit RSA keys for the Xeon computers as exemplary setting for HIP. The benchmark results presented in section 3.1 allow estimating the HIP performance for other key lengths as well. We give estimations for the computational overhead of the BEX for different RSA and DSA key lengths in section 6.1.3.4 We measure three different categories of processes:
6.1. Performance Evaluation
99
Figure 6.1: The HIP base exchange between the N770 and a 3.0 GHz Xeon server with 1536-bit RSA HIs for the initiator and 1024-bit RSA HIs for the responder. A 384-bit DH public keys was used. Cryptographic computations which are performed on the hosts in order to generate keys or to sign and verify messages Protocol processing which is performed in order to process packet parameters, send packets, and to modify the state of a HIP or LHIP association Packet processing which contains all operations required to process a packet including cryptographic computations and other protocol processing [Total processes] which contain packet processing, packet transmissions and other delays caused by external influences 6.1.3.1
HIP and LHIP Base Exchange on the N770
We first present the measurements for the HIP and LHIP base exchange on the N770. Our performance benchmark in section 3.1 suggests a delay in the order of 700 ms for the cryptographic operations during the BEX. We derive this synthetic estimation from summing up the benchmark results for the cryptographic computations on the initiator (N770) and the responder (3.2 GHz Xeon) during the BEX. Slightly slower processing on the responder is to be expected because it is a 3.0 GHz instead of 3.2 GHz Xeon. The real base exchange between the N770 and the Xeon host was completed in 677 ms. Figure 6.1 shows which parts of the BEX were most time-consuming on the N770. Time span I1 creation denotes the time which is necessary to construct and send the I1 packet. R1 processing and I2 creation denotes the time which is necessary for the packet processing of the R1 message and for constructing and sending the I2 message. This time span contains the RSA verification of the R1, the generation of the DH shared key, and the RSA signature generation for the R2 messages. Other protocol processing which is performed during the R1 processing and I2 creation time span such as setting up and modifying
100
6. Evaluation and Discussion
Figure 6.2: The LHIP base exchange between the the N770 and a 3.0 GHz Xeon server. the state of the hipd and setting up the IPsec SAs are denoted other. R2 processing denotes the time which is necessary in order to process the R2 packet. This time includes the cryptographic processing, namely the RSA signature verification, and the protocol processing required in order to complete the state setup which is denoted other. Other processes inside and outside the hipd cause an additional delay. The time for these processes was not explicitly measured. We determine this time span by calculating the difference between our measurement for the complete BEX and the time consumed by the packet-handling function and the RTT. The processing time for handling the I1 and I2 packet on the remote peer is denoted peer. The results show that most of the delay during the BEX is caused by the cryptographic processing. The PK operations consumed 98% of the time spent during the BEX. The RTT of 2 ms is not typical for the Internet. Increasing the amount of time for the RTT leads to more practical results. An RTT of 50 ms, for example, would add another 96 ms and result in a total of 773 ms. Even with realistic RTTs, the PK operations are responsible for most of the delay during the BEX. Figure 6.2 depicts the time measurements for the LHIP base exchange. The total duration of the BEX is 14.56 ms. The measurement results show that LHIP drastically reduces the time which is spent on packet processing during the BEX. This increased performance is achieved by removing all PK cryptography from the BEX. The hash chains for the IHC signatures have been pre-calculated before the BEX. On-line computation of the hash chains delays the LHIP BEX by 1.17 ms (8.0%) on the N770 initiator and by 0.07 ms (0.5%) on the responder (3.0 GHz Xeon). The LHIP measurements show that the computational cost of the LHIP BEX is reduced to the time which is needed for packet transmission and protocol processing. However, assuming realistic Internet RTTs of 50 ms, it takes 109 ms to open an LHIP association. Even though this total duration for a BEX to complete may seem high, LHIP offers significantly better performance than HIP for concurrent BEXs. With HIP, the N770 can establish 1.5 associations per second but 151.2 per second with LHIP. The impact of LHIP processing on the initial delay of a connection is low for typical Internet RTTs. For instance, with RTTs of 50 ms, the the duration for computations on the hosts is 6% (7 ms) of the total time of the BEX for LHIP (109 ms) while the computations consume 87% (672 ms) of the BEX time for for HIP with our test configuration. Even for long RTTs, the impact of HIP on the initial delay is high. For a 300 ms RTT, the HIP BEX takes 1273 ms and the delay caused by the computations for HIP packet processing is 672 ms (53%). An LHIP BEX takes 609 ms for an RTT of 300 ms and the delay caused by the LHIP packet processing is 6 ms (1%). These exemplary calculations show that the delay for LHIP computations has little negative influence on the delay of the BEX while the impact of the HIP computations on the BEX is significant even for long RTTs.
6.1. Performance Evaluation
101
Figure 6.3: The HIP base exchange between the a 3.2 GHz and a 3.0 GHz Xeon server. 1024-bit RSA HIs and 384-bit DH public keys were used. LHIP cuts down time for packet processing during the BEX to 6.1 ms processing time on the N770. This time contains the operations which are absolutely necessary in order to establish the HIP state on both hosts and to set up the IPsec tunnel. LHIP leaves little potential for further optimization as decreasing the time for packet processing from six to three milliseconds would only lead to marginal improvements, even on weak devices such as the N770. A main design goal of LHIP was to reduce the overhead of the PK operations during the BEX. Our LHIP design has succeeded in this point as it enables LHIP to completely remove all PK operations from the BEX without introducing other CPU-intensive processing steps. The BEX performance improvement in LHIP is also very important because a HIP association is established with every peer a HIP host communicates with. Introducing a long delay for every association is problematic especially when it is unclear whether the services of HIP, namely authentication, encryption, and mobility support, are required or not. The demand for these services is typically not clear before the association is established. Developing reliable heuristics in order to determine the need for these services before establishing an association is difficult. Requiring user interaction for each association reduces the usability of HIP. Therefore, the most practical solutions are to use HIP for all associations or for none. The LHIP BEX allows letting the applications determine whether encryption and authentication is required after the BEX and provides mobility and multihoming support with low computational overhead. 6.1.3.2
HIP and LHIP Base Exchange on the Xeon Computer
In our second measurement setup, we establish a HIP association between the 3.2 GHz Xeon and the 3.0 GHz Xeon computers. We use the same combination of key lengths as in our first test. Both hosts used 1024-bit RSA keys and a 384-bit DH keys. Our benchmark suggests an estimated delay of 19.45 ms for the cryptographic computations
102
6. Evaluation and Discussion
Figure 6.4: The LHIP base exchange between the the 3.2 GHz and the 3.0 GHz Xeon server. during BEX. Again, the responder is slightly slower than the host on which the benchmark was computed. Confirming our estimation, the measurement shows that establishing a HIP association between the two hosts takes 22.74 ms. Figure 6.3 shows the time distribution of the BEX for the Xeon server. The PK operations on both hosts consumed 20.25 ms which is 89% of the BEX. The total delay caused by packet transmission amounts to 0.22 ms which is 1% of the time consumed by the PK-operations. A delay of 0.5 ms was caused by other processes in or outside the hipd. An RTT of 50 ms increases the BEX duration to 122.5 ms which means that even on the Xeon hosts, the PK operations delay the BEX for realistic transmission times by 17%. Figure 6.4 shows the processing time for the packet-handling functions in LHIP. The Xeon hosts establish a LHIP association in 0.95 ms. The time consumed by the LHIP packet processing was 0.65 ms. Assuming an RTT of 50 ms, it takes 100.73 ms to complete the BEX. 6.1.3.3
Comparison of the LHIP with the HIP BEX
The charts above show that LHIP drastically reduces the initial delay before a HIP association is functional for the N770 as well as for the Xeon computers. The figures also show that the additional overhead for establishing the LHIP state and exchanging the hash chain anchors is negligible. Table 6.1 summarizes the result. LHIP reduces the time for packet processing on the N770 from 661.62 ms to 6.61 ms or 1%. The result for the Xeon servers is similar. LHIP reduces the processing times of the packets to 3% of the processing time for HIP on the 3.2 GHz Xeon (initiator) and to 2% on the 3.0 GHz Xeon (responder). The results for HIP mainly depend on the selection of PK algorithms and key lengths. Therefore, making a general statement about how LHIP performs compared to HIP is difficult. We give estimations of the computational overhead of HIP for different key lengths in section 6.1.3.4 which allows to compare LHIP with HIP. The time for pre-creating all four hash chains which consist of two 20-element chains and two 2-element chains is not included in the measurements for the I2 creation or R2 creation, respectively, because it was performed before the BEX. However, the hash chain computation is inexpensive. Creating two 20-element and two 2-element hash chains takes 1.17 ms on the N770 while the Xeon 3.2 GHz and the Xeon 3.0 GHz computers generate the hash chains in 0.06 ms or 0.07 ms, respectively. The standard deviation for all measurements in table 6.1 is below 10 % of the corresponding result except for the process R1 send I2 measurement for HIP which is 25% and the short I1 processing on the N770 for LHIP which is 33%. The high percentage of the standard deviation is caused to the short time spans which are measured, the influence of process
6.1. Performance Evaluation
103
Table 6.1: Time consumed by operations during the BEX
Send I1 Process I1, send R1 Process R1 send I2 Process I2, send R2 Process R2 Processing (total) Hash Chain creation
Initiator N770 Xeon 3.2 GHz HIP LHIP HIP LHIP 1.23 ms 1.27 ms 0.06 ms 0.06 ms – – – – 645.91 ms 4.35 ms 10.71 ms 0.11 ms – – – – 14.48 ms 0.99 ms 0.32 ms 0.08 ms 661.62 ms 6.61 ms 11.10 ms 0.36 ms – 1,17 ms – 0.06 ms
Responder Xeon 3.0 GHz HIP LHIP – – 0.04 ms 0.09 ms – – 10.88 ms 0.24 ms – – 10.72 ms 0.29 ms – 0.07 ms
scheduling and the interaction with the IPsec modules. The operations which are not performed by an initiator or a responder are marked with a dash. Note that LHIP provides less security than HIP. The given values assume that none of the hosts has to authenticate during the LHIP handshake. Host authentication delays the I2 or R2 generation by the time which is required in order to compute the RSA signature. The I2 and R2 processing are delayed by the time it takes to verify the RSA signature. 6.1.3.4
HIP BEX Performance Estimation
The measurement results and the benchmark results presented in section 3.1 allow estimating the computational overhead of HIP for different key lengths. We calculated estimations for RSA and DSA HIs for key lengths ranging from 512 to 3072 bits. The estimations are based on the benchmark results and the time spans which are independent from the PK keys derived from our BEX measurements. Each estimation result contains: • Two RSA or DSA signature verifications for the initiator and one RSA or DSA signature verification for the responder with the corresponding key lengths. These values are taken from the benchmark. • One RSA or DSA signature creation for the initiator and for the responder with the corresponding key lengths. These values are also taken from the benchmark. • One DH shared key computation with a 384-bit key for the initiator and the responder. We choose this short key length because payload encryption is not necessary in scenarios where LHIP is applicable. Therefore, longer DSA keys would introduce an unnecessary computational overhead which would bias the estimation results in favor for LHIP. The DH computation results are also taken from the benchmark. • A fixed time span for packet processing. We derive this time span from our BEX measurements on the different platforms. It contains the time which was consumed by operations which are not influenced by the PK operations. This amount of time is 7.99 ms for the N770 and 0.49 ms for the 3.2 GHz server when they act as initiators and 0.58 ms for the 3.0 GHz server when it acts as responder. The estimations do not include the delay other processes have caused inside and outside the hipd. Therefore, the estimations are taken in favor for HIP as we assume that all packets
104
6. Evaluation and Discussion
are processed without any delay from further packet processing or from the operating system. Furthermore, the estimations assume that only one BEX is performed at the same time. Simultaneous BEX as they have to be expected in real applications slow down the BEX even further. We estimate the processing time for the 3.0 GHz server with the benchmark results of the 3.2 GHz Xeon benchmark. Therefore, the influence of the responder is slightly underestimated in favor of HIP. However, the differences between the processing power of these hosts is small and therefore the impact is small compared to the variance of the RTT in the Internet and the influence of other processes on the hosts. Our estimations do not contain values for the RTT. Adding two RTTs to the estimations allows to estimate the delay during the BEX for different network conditions and infrastructures. We rounded the results to a precision of one millisecond to indicate that the results are estimations. However, we expect valid estimations because the same functions and the same libraries have been used for the benchmark as well as for HIP. Nevertheless, small differences must be expected due to runtime effects and the influence of different keys. Our estimations are made for the same combination of initiator and responder as for our test. The N770 and the Xeon 3.2 GHz Xeon always act as initiator and the 3.0 GHz Xeon always acts as responder. Table 6.2: Estimated computational overhead of the BEX for the two Xeon computers using RSA HIs Initiator Responder Key length 512 bits 1024 bits 1536 bits 2048 bits 3072 bits 512 bits 7 ms 7 ms 8 ms 8 ms 9 ms 1024 bits 21 ms 21 ms 22 ms 22 ms 23 ms 57 ms 57 ms 57 ms 58 ms 59 ms 1536 bits 2048 bits 134 ms 134 ms 134 ms 135 ms 136 ms 408 ms 409 ms 409 ms 410 ms 411 ms 3072 bits
Table 6.3: Estimated computational overhead for the BEX for the N770 and the 3.0 GHz Xeon computer using RSA HIs Initiator Responder Key length 512 bits 1024 bits 1536 bits 2048 bits 3072 bits 512 bits 89 ms 104 ms 130 ms 154 ms 266 ms 1024 bits 247 ms 262 ms 288 ms 312 ms 423 ms 1536 bits 662 ms 677 ms 703 ms 727 ms 839 ms 2048 bits 1,278 ms 1,293 ms 1,319 ms 1,343 ms 1,455 ms 3072 bits 4,434 ms 4,448 ms 4,474 ms 4,499 ms 4,610 ms The computational overhead of the LHIP BEX is 6.9 ms for the BEX between the N770 and the 3.0 GHz Xeon server and 0.65 ms for the BEX between the Xeon computers. The comparison with our HIP estimation show that LHIP reduces the computational overhead to a fraction of the computational overhead of HIP even when short RSA and short DH keys are used by both communicating peers. The combination of RSA 512 bit1 and DH 384-bit keys lead to the shortest estimated delay on the N770 and the Xeon host. Nevertheless, LHIP outperforms HIP by a factor of 13 for the BEX between the N770 and the 3.0 GHz 1
Note that 512-bit keys are considered unsafe (cf. section 3.1.3)
6.1. Performance Evaluation
105
Table 6.4: Estimated computational overhead for the BEX for the two Xeon computers using DSA HIs Initiator Responder Key length 512 bits 1024 bits 1536 bits 2048 bits 3072 bits 512 bits 4 ms 6 ms 9 ms 13 ms 24 ms 5 ms 7 ms 10 ms 14 ms 25 ms 1024 bits 1536 bits 6 ms 8 ms 10 ms 15 ms 26 ms 2048 bits 8 ms 10 ms 12 ms 17 ms 28 ms 3072 bits 12 ms 14 ms 16 ms 21 ms 32 ms Table 6.5: Estimated computational overhead for the BEX for the N770 and the 3.0 GHz Xeon computer using DSA HIs Initiator Responder Key length 512 bits 1024 bits 1536 bits 2048 bits 3072 bits 512 bits 107 ms 277 ms 616 ms 871 ms 2,306 ms 1024 bits 177 ms 346 ms 685 ms 940 ms 2,375 ms 310 ms 479 ms 818 ms 1,073 ms 2,508 ms 1536 bits 2048 bits 421 ms 591 ms 930 ms 1,185 ms 2,620 ms 983 ms 1,152 ms 1,491 ms 1,746 ms 3,181 ms 3072 bits Xeon and a factor of 6 for the BEX between the Xeons. However, short RSA and DSA keys are not suitable as for long term identifiers (cf. section 3.5.3). Longer key lengths slow down the BEX considerably. Even if the N770 uses short keys it must verify the signatures of its peers. With short 512-bit HIs for the N770 and a 1536-bit DSA key for the 3.0 GHz server, the processing time for the BEX lasts about 616 ms. This process is slow for intermediate and long DSA keys. Using LHIP instead of HIP enables the peers to use their long-lasting identifiers for both, unencrypted and unauthenticated LHIP associations and full HIP associations. LHIP reduces the computational cost during the BEX to 2% of the computational cost of HIP BEX for 1024-bit RSA and DSA keys for an association between the N770 and the Xeon 3.2GHz computer. Therefore, LHIP achieves the high-level goal LH1 - performance for the BEX.
6.1.4
HIP and LHIP Update
The LHIP authentication layer adds preceding and trailing IHC signature messages to every HIP UPDATE message in order to authenticate these messages. This means that more packets must be processed and transmitted. This section will determine the overhead of our IHC signature scheme and discuss how the IHC signatures perform in different scenarios. Each HIP UPDATE message is accompanied by three IHC signature packets. The PSIG, TRIG and ACK packet. The IHC signatures replace the RSA and DSA signatures in the update packets. Therefore, we compare IHC signatures to RSA signatures. We measured the processing time of IHC signature packets on the N770 and the 3.2 GHz server. Table 6.6 summarizes the results. The results are the mean values derived from 150 IHC signature processes during LHIP updates. The measurements for RSA 1536 are also depicted in order to make comparisons with the RSA signatures easier. The IHC signatures replace the RSA and DSA signatures in the update packets. Therefore, we compare the efficiency of IHC signature to the efficiency of these PK signatures. The
106
6. Evaluation and Discussion
Table 6.6: Performance of IHC and RSA signatures N770 Xeon 3.2 GHz IHC signatures Send PSIG 0.33 ms 0.03 ms Process PSIG, send TRIG 1.47 ms 0.05 ms Process TRIG, send MSG 1.52 ms 0.05 ms Verify MSG, send ACK 1.60 ms 0.05 ms 0.49 ms 0.05 ms Process ACK Sender(total) 2.34 ms 0.13 ms 3.07 ms 0.10 ms Receiver (total) RSA and DSA signatures RSA 1024 sign 181.32 ms 9.09 ms 578.70 ms 27.03 ms RSA 1536 sign DSA 1024 sign 96.71 ms 1.34 ms 229.27 ms 2.18 ms DSA 1536 sign RSA 1024 verify 10.53 ms 0.15 ms 23.47 ms 0.23 ms RSA 1536 verify DSA 1024 verify 118.73 ms 1.61 ms DSA 1536 verify 287.76 ms 2.81 ms IHC signatures only consume 1.2 % of the processing time of a 1024-bit RSA signature and 2.5% of the processing time of a 1024-bit DSA signature on the tablet. Even the N770 can perform all computations that are necessary to send an IHC signed message in less than 2.5 ms. It can receive IHC signed messages with a computational overhead of 3.07 ms. Depending on the application scenario, hosts may open HIP or LHIP associations to several peers. Mobile hosts have to update all of these associations whenever they move. Assuming that the N770 uses a 1024-bit RSA HI and has 10 open associations to other HIP hosts, it must compute 20 RSA signatures in order to send the first UPDATE messages and the second UPDATE messages to all peers. This results in a computational cost of 3626.4 ms for processing the RSA signatures for 10 updates. In contrast to RSA signed updates, transmitting 10 IHC signed updates consisting of an IHC signed message from the initiator to the responder and one IHC signed message from the responder to the initiator2 causes a computational cost of 55 ms for packet processing on the N770 and 2.3 ms on the Xeon host. This reduces the processing time for signing LHIP update messages to 1.5% of the computational cost of HIP with 1024-bit RSA HIs. Therefore LHIP achieves the high level goal LH1 - performance for the update process. IHC signatures significantly reduce the time for signing UPDATE messages on weak hosts. However, they introduce an RTT dependent delay due to the necessary interaction. As RSA, DSA and HMAC signatures do not require interaction. Therefore, these signatures can be delivered with a single transmission. IHC signatures delay the message delivery by one additional RTT because the PSIG and TRIG packets must be exchanged before the actual message is sent. The efficiency of IHC signatures, therefore, mainly depends on the link between two peers and the computational power of the hosts. The IHC signature process is faster than the RSA and DSA protected UPDATE messages if the time for 2
The third LHIP UPDATE packet is not protected (see section 4.3.2 for details).
6.1. Performance Evaluation
107
processing the IHC signature on both peers plus one RTT is lower than the time for the RSA or DSA signature creation3 . The PSIG creation and the TRIG handling on the N770 consumes 1.85 ms processing time. The PSIG handling on the 3.0 GHz server took 0.05 ms. Therefore, sending IHC signed signatures from the N770 to the 3.0 GHz server is less time consuming than 1536-bit RSA signatures as long as the RTT between both peers is not higher 578 ms. The N770 calculates 1024-bit RSA signatures in 181.32 ms. This means that IHC signatures from the N770 to the Xeon host are faster if the RTT is below 178.88 ms. The IHC signatures delay the message delivery for higher RTTs. As a rule of thumb, IHC signatures require less time if the RTT of the network is smaller than the time for the public key signature generation. LHIP-aware middleboxes can use the IHC signature packets to verify messages. This means that these middleboxes do not have to compute RSA or DSA verifications. Our improved IHC signature scheme reduces the amount of data which must be buffered by the middlebox. Verifying an IHC signature only requires to buffer the small pre-signature of the message in order to verify the message in the MSG packet. Nevertheless, middleboxes must provide buffer space to store the pre-signatures. However, HIP-aware middleboxes must provide buffer space for HIP associations, too. They must store the HIs of the communication peers in order to verify the RSA and DSA signatures. We have not measured the impact of IHC signatures on HIP-aware middleboxes. These measurements are future work,
6.1.5
LHIP to HIP Upgrade
We used the N770 and the 3.2 GHz Xeon host as initiator of the LHIP upgrade and the Xeon 3.0 GHz host as responder. The N770 used 1536-bit HIs and the Xeon hosts used 1024-bit RSA HIs. A 384-bit DH key was used for the upgrade measurements. The LHIP upgrade is a two-way communication process. Table 6.7 shows the measurement results for the upgrade steps. In the beginning of the upgrade process, the initiator computes the shared secret and sends a signed UPGRADE message to the responder. This step is denoted send UPGRADE in 6.7. The responder processes the update, modifies its state and sends back its signed UPGRADE packet. This process is denoted process UPGRADE, send UPGRADE. The initiator verifies the UPGRADE packet of the responder and completes the IPsec setup. This last step is denoted finish UPGRADE. Table 6.7: Performance of the LHIP upgrade process Initiator Responder N770 Xeon 3.2 GHz Xeon 3.0 GHz Send UPGRADE 624.86 ms 10.67 ms – Process UPGRADE, send UPGRADE – – 11.39 ms Finish UPGRADE 17.19 ms 0.59 ms – The results in table 6.7 are the mean values of 200 upgrade processes. The standard deviation is below 10% for all results, except for the short finish Upgrade process. The standard deviation for this result is 15% of the result for the Xeon host and 16% for the N770. . 3 The RSA or DSA signature verification is optional for HIP hosts because RSA and DSA signatures in HIP update packets are mainly used by middleboxes, while HIP hosts can use the HMAC signatures for message authentication.
108
6. Evaluation and Discussion
The computational overhead for the LHIP upgrade is similar to the computational overhead of the BEX because the same cryptographic operations are performed as in the base exchange in order to guarantee the same security properties for HIP associations after an upgrade as for HIP associations which have been established with a HIP BEX. The processing time for all upgrade messages is 642.05 ms on tablet while the processing time for the BEX is 662.10 ms. The differences are due to the fact that only one RSA signature verification is necessary in order to perform an upgrade while two RSA verifications are necessary to verify the R1 and the R2 messages and due to the reduced packet processing and state handling. Moreover, two UPGRADE instead of four BEX messages are transmitted in order to upgrade an association. Thus, the upgrade process saves one RTT and one signature verification compared to the re-establishment of a regular HIP association.
6.1.6
HIP and LHIP Close Process
The HIP close process utilizes HMAC signatures to protect the CLOSE messages from forgery. Furthermore, HIP uses RSA and DSA signatures in order to allow middleboxes to authenticate the CLOSE messages. LHIP does not need this protection as middleboxes can verify the IHC signatures. We measured the time which is required in order to close a HIP and an LHIP association. Table 6.8 shows the result of our measurements. The results are the mean values from 200 close procedures. The standard deviation for each measurement is given in brackets. All values are in milliseconds.
Send CLOSE Handle CLOSE
Table 6.8: DH shared key generation N770 Xeon 3.2 GHz HIP LHIP HIP LHIP 595.89 (18.04) 8.24 (7.24) 10.33 (0.46) 0.28 (0.15) 14.84 (4.53) 2.16 (1.49) 0.41 (0.36) 0.25 (0.23)
The public key operations during the closing process consumed 97% (590.97 ms) of the processing time on the tablet and 86% (9.44 ms) of of the processing time on the Xeon computer. The results in table 6.8 show the complete handling of the close messages including the measures required to tear down the HIP and LHIP associations. LHIP close messages do not require the services of the authentication layer. Therefore, they do not introduce an additional communication overhead. Hash chain protected CLOSE messages reduce the computation time which is required in order to close a HIP association on the tablet from 610.73 ms to 10.4 ms which means a reduction to 1.7% compared to a HIP association with 1536-bit RSA HIs for the initiator and 1024-bit RSA identifiers for the responder. The time for closing the association between the Xeon hosts is reduced from 10.4 ms to 0.53 ms which means a reduction of 5%. Again, the potential for LHIP to reduce the overhead of the HIP closing process depends on the choice of PK algorithms and key lengths which are used for HIP. CLOSE messages which are delayed due to slow computations do not cause noticeable delays for the user. However, they consume CPU time and might disrupt other CPU-demanding applications.
6.2
Discussion
We defined four high-level goals for LHIP in section 3.4. These high-level goals determine how LHIP should perform and which security properties it must provide. In this section, we discuss whether LHIP achieves its high-level goals.
6.2. Discussion
6.2.1
109
LH1 - Performance
Our performance measurements show that LHIP can be used on hosts with low processing power, such as mobile devices, without imposing long delays for establishing and maintaining an LHIP association. IHC signatures drastically reduce the computational overhead of UPDATE messages. Even devices with little CPU resources, such as the N770, are capable of performing multiple location updates with different peers at the same time. However, the delays caused due to long RTTs affect the LHIP update process stronger than the HIP update process. LHIP CLOSE and UPGRADE messages are protected by single hash chain elements. The generation and verification of these elements is cheap in terms of CPU cycles. LHIP speeds up the closing procedure as it makes RSA and DSA signatures in the close messages unnecessary. The LHIP to HIP upgrade process requires both hosts to compute the shared secret and the RSA signatures. The computational overhead is, therefore, similar to the overhead of the BEX. LHIP reduces the computational cost of HIP during the BEX and the update process to less than 2.5% of the cost of HIP with 1024-bit RSA or DSA HIs. Therefore LHIP achieves its first high-level goal LH1 - performance.
6.2.2
LH2 - Protocol Security
LHIP provides considerably less security than HIP. It does not authenticate the HIs, nor does it provide payload encryption. However, it decreases the computational overhead of HIP in scenarios which do not require these security properties. It signs UPDATE messages with IHC signatures and, therefore, guarantees that attackers can not forge important HIP control messages. The improved IHC signatures are not susceptible to MITM attacks, in case of simultaneous signature packets from both peers, any more. LHIP also protects the CLOSE messages and the UPGRADE messages in order to prevent attacks which aim at state manipulation and connection disruption. However, the first contact between both hosts must be authentic. LHIP can not protect against MITM attacks without authenticated I2 and R2 messages. LHIP allows to use RSA and DSA signatures for these packets, depending on whether signatures are necessary or not. Hosts can request strong authentication from their peer if required. Nevertheless, the basic functionality of LHIP does not require PK authentication. LHIP provides safe mobility updates and protects all important protocol processes with hash chains and IHC signatures. Therefore, LHIP achieves the second high-level goal LH2 - protocol security. However, the question how to protect the LHIP upgrade process with client puzzles remains.
6.2.3
LH3 - Namespace Security
LHIP uses RSA and DSA signatures in case of name space conflicts and in order to prevent harmful impersonation attacks. The optional authentication of the I2 and R2 messages and the authentication of UPGRADE packets ensures that a host can not block HIP or LHIP nodes. Furthermore, these signatures prevent attacks which aim at impersonating a HIP node by first establishing an LHIP association and then upgrading to HIP. We are not aware of further attacks on the HIP namespace which are not prevented by these measures. LHIP, therefore, achieves its high-level goal LH3 - namespace security.
110
6.2.4
6. Evaluation and Discussion
LH4 - Compatibility
LHIP was designed to interoperate with pure HIP implementations. The decision whether an LHIP association is possible or not, is taken during the BEX. LHIP hosts always establish HIP associations when they communicate with non-LHIP-aware hosts. This behavior was successfully tested for an association with an LHIP-unaware host as responder and an association with an LHIP-unaware host as initiator. The HIP implementation on the plain HIP hosts was unmodified. This shows that LHIP hosts can interact with non-LHIP-aware HIP hosts. Like HIP, LHIP supports packet inspecting middleboxes. These middleboxes can learn the SPIs, HIs, and anchor values from the BEX and UPDATE packets. Middleboxes can verify the LHIP UPDATE messages efficiently. However, the way of authentication differs from the way HIP authenticates UPDATE packets. Therefore, LHIP provides the same features for middleboxes but it requires modifying HIP-aware middleboxes. At this time, this is no real limitation as only experimental HIP-aware middleboxes are in use. They are not deployed in large scale. Implementing LHIP-aware middleboxes and measuring their performance is future work. LHIP does not modify the way HIP works in general. The LHIP authentication layer can be adapted in order to support existing and future HIP extensions. LHIP supports the mobility and multihoming extensions. Other extensions like rendezvous servers and opportunistic HIP are not supported yet. Adapting the LHIP authentication layer in order to support these extensions is future work as well. LHIP can interact with unmodified HIP implementations and supports middleboxes. It reuses the HIP name resolution infrastructure and the HI namespace. LHIP, therefore, achieves the third high-level goal LH4 - compatibility. However, some aspects of HIP, like extensions and middlebox implementations require more research and development to be conducted.
6.2.5
Limitations
LHIP speeds up the association establishment phase, the update, and the close process on weak devices which are not capable of performing PK cryptography in adequate time. Hosts with sufficient CPU power, however, do not require the use of LHIP. The benefit of LHIP for modern consumer computers is marginal. LHIP might even slow down the update process on these devices, depending on the RTT between the communication peers. Therefore, it is not a general replacement for HIP in scenarios which do not require host authentication and payload encryption. The security of LHIP depends on the assumption that no MITM attack takes place during the BEX. LHIP can not protect against these attacks as it does not necessarily verify the HIs of the hosts. LHIP should, consequently, only be used if host authentication is not required or is provided by the application. Furthermore, payload encryption is out of scope for LHIP because the communication peers do not share a secret symmetric key.
7. Summary and Outlook We have presented LHIP, the lightweight authentication extension for the Host Identifier Protocol. LHIP enables CPU poor devices to use HIP mobility and multihoming support without the computation of costly PK operations. In order to achieve this, we designed the LHIP authentication layer which secures HIP UPDATE messages with interactive hash chain based signatures. These signatures allow LHIP hosts and LHIP-aware middleboxes to ensure the authenticity and integrity of LHIP UPDATE messages without using PK cryptography. Other messages, like the CLOSE messages, which are sent in order to tear down an LHIP association, are protected as well. LHIP only uses PK cryptography in case of namespace conflicts and attacks. LHIP therefore offers the same support for decentralized end-host mobility as HIP does for hosts with few CPU resources without being less secure than the IP protocol. We have improved the IHC signatures in order to secure them against MITM attacks and to increase their efficiency. The improved IHC signatures are easier to handle for middleboxes and increase the throughput of the IHC signature scheme. The performance measurements of the IHC signatures shows that they are inexpensive in terms of CPU usage. However, they increase the communication overhead. Their efficiency depends on the computational power of the peers and on the RTT of the network link between the peers. We have proposed an efficient way to transform an LHIP association into a HIP association. This transformation only requires two messages to be exchanged and has a computational overhead which is similar to the computational overhead of the HIP base exchange. LHIP was designed for compatibility with pure HIP implementations. The LHIP handshake allows seamless fallback to a HIP association, in case one of the communication peers is a pure HIP host. LHIP reuses the HIP namespace and the name resolution infrastructure. It furthermore provides a way for middleboxes to authenticate IHC signed packets without using PK cryptography. LHIP and HIP can be supported by hybrid implementations. We have implemented a hybrid LHIP and HIP protocol instance in order to show the feasibility of the LHIP. The implementation shows that LHIP reduces the computational cost of the HIP protocol to a level which can be handled by mobile devices with few CPU resources.
112
7. Summary and Outlook
LHIP offers opportunities for further work and completion. It supports the basic features of HIP but HIP extensions such as opportunistic HIP or the HIP rendezvous extensions have not been considered yet. Examining the implications of these extensions for LHIP will be done in further research. The LHIP interaction with middleboxes also requires more research to be conducted. LHIP provides a way for middleboxes to authenticate UPDATE messages with the IHC signature scheme. Implementing and evaluating this authentication mechanism is future work. The application interface of LHIP provides access to the basic functions of LHIP. However, it does not allow applications to control the behavior of LHIP in a fine-grained way. More research and work is necessary in order to define a consistent and complete API. The LHIP protocol extension was tested on the Nokia 770 Internet Tablet. Implementing and evaluating the LHIP extension for other HIP implementations, platforms, and operating system in order to compare their LHIP performance reqires further research and development. LHIP succeeds in providing decentralized end-host mobility to hosts with few CPU resources. It reduces the computational cost of the relevant HIP protocol functionality to less than 2.5% compared with HIP using 1024-bit HIs while allowing hosts to use long-term identifiers. With this performance LHIP is beyond all our expectations and meets our requirements for LHIP with ease. Furthermore, it offers the same features concerning safe mobility and multihoming support. IHC signatures have proven to be a very versatile tool to support lightweight security. We hope that our improved IHC signature scheme will help researchers and developers who work in other fields of research to achieve lightweight authentication for other protocols and purposes. Furthermore, we hope that LHIP will boost the deployment of HIP by making HIP and LHIP an attractive and efficient combination on truly mobile devices.
References [AN02]
J. Arkko and P. Nikander. Weak Authentication: How to Authenticate Unknown Principals without Trusted Parties. Security Protocols Workshop, pages 5–19, 2002.
[Atk95a]
R. Atkinson. IP encapsulating security payload (ESP). RFC 1827, Internet Engineering Task Force, August 1995.
[Atk95b]
R. Atkinson. Security architecture for the internet protocol. RFC 1825, Internet Engineering Task Force, August 1995.
[BCK96]
M. Bellare, R. Canetti, and H. Krawczyk. Keying hash functions for message authentication. Lecture Notes in Computer Science, 1109:1–??, 1996.
[BS04]
S. A. Baset and H. Schulzrinne. An Analysis of the Skype Peer-to-Peer Internel Telephony Protocol. Arxiv preprint cs.NI/0412017, 2004.
[CLK04]
M. Chang, M. Lee, and S. Koh. A Transport Layer Mobility Support Mechanism. Lecture notes in computer science, pages 287–296, 2004.
[Dam90]
I. Damgård. A design principle for hash functions. In CRYPTO ’89: Proceedings of the 9th Annual International Cryptology Conference on Advances in Cryptology, pages 416–427, London, UK, 1990. Springer-Verlag.
[DH76]
W. Diffie and M. E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, IT-22(6):644–654, 1976.
[FIP99]
PUB FIPS. 46-3, Data Encryption Standard (DES). National Institute for Standards and Technology, 25, 1999.
[HC98]
D. Harkins and D. Carrel. The Internet Key Exchange (IKE). RFC 2409 (Proposed Standard), November 1998. Obsoleted by RFC 4306, updated by RFC 4109.
[Hen06]
T. Henderson. End-host mobility and multihoming with the host identity protocol. Internet-Draft (work in progress) Version 4, IETF, 2006.
[HPJ01]
Y. Hu, A. Perrig, and D. Johnson. Packet leashes: A defense against wormhole attacks in wireless ad hoc networks. Technical report, Department of Computer Science, Rice University, December 2001.
[HSV+ 05] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. Stenberg. UDP encapsulation of ipsec ESP packets. RFC 3948, Internet Engineering Task Force, January 2005.
114
References
[Jou04]
A. Joux. Multicollisions in iterated hash functions. application to cascaded constructions. In CRYPTO, pages 306–316, 2004.
[KA98]
S. Kent and R. Atkinson. Security architecture for the internet protocol. RFC 2401, Internet Engineering Task Force, November 1998.
[Kam04]
D. Kaminsky. Md5 to be considered harmful someday. Cryptology ePrint Archive, Report 2004/357, 2004. http://eprint.iacr.org/.
[KBC97]
H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104 (Informational), February 1997.
[KK03]
T. Kivinen and M. Kojo. More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). RFC 3526, May 2003.
[KTKG05] M. Komu, S. Tarkoma, J. Kangasharju, and A. Gurtov. Applying a cryptographic namespace to applications. In DIN ’05: Proceedings of the 1st ACM workshop on Dynamic interconnection of networks, pages 23–27, New York, NY, USA, 2005. ACM Press. [Lam81]
L. Lamport. Password authentication with insecure communication. Commun. ACM, (11):770–772, 1981.
[LLMM00] L. Lenstra, M. Lioen, M. Montgomery, and P. Muett. Factorization of a 512–bit RSA Modulus. Advances in Ciyptology. Eurocrypt, pages 1–17, 2000. [Mer88]
R. C. Merkle. A digital signature based on a conventional encryption function. In CRYPTO ’87: A Conference on the Theory and Applications of Cryptographic Techniques on Advances in Cryptology, pages 369–378, London, UK, 1988. Springer-Verlag.
[Mer89]
R. C. Merkle. One way hash functions and des. In CRYPTO, pages 428–446, 1989.
[Mir05]
I. Mironov. Hash functions: Theory, attacks, and applications. Technical Report MSR-TR-2005-187, Microsoft Research, November 2005.
[MJN06]
R. Moskowitz, P. Jokela, and P. Nikander. Using esp transport format with hip. Internet-Draft (work in progress) Version 3, IETF, 2006.
[MNJH06] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson. Host identity protocol. Internet-Draft (work in progress) Version 6, IETF, 2006. [Mol99]
R. Molva. Internet security architecture. Computer Networks (Amsterdam, Netherlands: 1999), 31(8):787–804, 1999.
[NAO04]
P. Nikander, J. Arkko, and B. Ohlman. Host identity indirection infrastructure (hi3). In The Second Swedish National Computer Networking Workshop, November 2004.
[Nat95]
National Institute of Standards and Technology. FIPS PUB 180-1: Secure Hash Standard. April 1995. Supersedes FIPS PUB 180 1993 May 11.
References
115
[Nat00]
National Institute of Standards and Technology. FIPS PUB 186-2: Digital Signature Standard (DSS). January 2000.
[NB06]
E. Nordmark and M. Bagnulo. Level 3 multihoming shim protocol. InternetDraft (work in progress) Version 5, IETF, May 2006.
[NL06]
P. Nikander and J. Laganier. Host identity protocol (HIP) domain name system (DNS) extensions. Internet-Draft (work in progress) Version 6, IETF, 2006.
[NM06]
P. Nikander and J. Melen. A bound end-to-end tunnel (BEET) mode for esp. Internet-Draft (work in progress) Version 5, IETF, 2006.
[PCTS02]
A. Perrig, R. Canetti, D. Tygar, and D. Song. The TESLA broadcast authentication protocol. Cryptobytes, 5(2), 2002.
[Pro]
InfraHIP Project. HIPL website, http://infrahip.hiit.fi/hipl/.
[PSC+ 05]
A. Perrig, D. Song, R. Canetti, J. D. Tygar, and B. Briscoe. Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction. RFC 4082 (Informational), June 2005.
[rfc96]
IP mobility support. RFC 2002, Internet Engineering Task Force, October 1996.
[rfc06]
Host identity protocol (HIP) architecture. RFC 4423, Internet Engineering Task Force, May 2006.
[Riv92]
R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321 (Informational), April 1992.
[RS96]
R. L. Rivest and A. Shamir. Payword and micromint: Two simple micropayment schemes. In Security Protocols Workshop, pages 69–87, 1996.
[RSA77]
R. L. Rivest, A. Shamir, and L. M. Adelman. A method for obtaining digital signatures and public-key cryptosystems. Technical Report MIT/LCS/TM-82, 1977.
[SAZ+ 02]
I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana. Internet indirection infrastructure. In SIGCOMM ’02: Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications, pages 73–86, New York, NY, USA, 2002. ACM Press.
[Sch93]
B. Schneier. Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish). Fast Software Encryption, Cambridge Security Workshop Proceedings, pages 191–204, 1993.
[SPK+ 06]
V. Schmitt, A. Pathak, M. Komu, L. Eggert, and M. Stiemerling. Hip extensions for the traversal of network address translators. Internet-Draft (work in progress) Version 1, IETF, 2006.
[Sta01]
A.E. Standard. Federal Information Processing Standard Publications (FIPS PUBS) 197, 2001.
24. August 2006.
URL:
116
References
[Ste97]
W. Stevens. TCP slow start, congestion avoidance, fast retransmit, and fast recovery algorithms. RFC 2001, Internet Engineering Task Force, January 1997.
[STS]
T. Sander and A. Ta-Shma. Auditable, Anonymous Electronic Cash. Advances in Cryptology–CRYPTO, 99:555–572.
[TY04]
V. Torvinen and J. Ylitalo. Weak context establishment procedure for mobility management and multi-homing. In IP TC-6 TC-11: Proceedings of the 8th IFIP TC-6 TC-11 Conference on Communications and Multimedia Security, 2004.
[Wät04]
Dietmar Wätjen. Kryptographie. Spektrum Akademischer Verlag. Berlin, 2004.
[WY05]
X. Wang and H. Yu. How to break md5 and other hash functions. In EUROCRYPT, pages 19–35, 2005.
[YN04]
J. Ylitalo and P. Nikander. Blind: A complete identity protection framework for end-points. Twelfth International Workshop on Security Protocols, Cambridge, England, April, 2004.
[YTN04]
J. Ylitalo, V. Torvinen, and E. Nordmark. Weak identifier multihoming protocol (WIMP). Internet-Draft (work in progress) Version 1, IETF, 2004.
[Zha98]
K. Zhang. Efficient protocols for signing routing messages. Proceedings of the Symposium on Network and Distributed Systems Security (NDSS’98), 1998.
