Secure Access Over Multi-Hop Relay Extensions of Public Networks Rainer Falk Hannes Tschofenig
Anand Prasad
Siemens Corporate Technology D-81730 Munich
DoCoMo Comm. Labs. Europe GmbH D-80687 Munich
{rainer.falk;hannes.tschofenig}@siemens.com
[email protected]
Abstract— The use of relays as multi-hop extension of public networks is expected to play an important role for future mobile communication systems as they could provide simple and cost-efficient extension of coverage for access points. This paper describes the reference model, security requirements, and required security solution components to protect the access to a publicly accessible infrastructure network (e.g., to the Internet or to an operator network) over a multi-hop extension set-up and operated by the public network operator. While secure access to the public network by users is based on the same preconditions as direct access to an access point, the relay extension has to be protected additionally to ensure its correct operation and to prevent that it is misused for other purposes than accessing the public network.
Key words: security, multi-hop, network access 1.
INTRODUCTION
Ambient Networks [1] is a large-scale collaborative project within the European Union 6th Framework Program that investigates future communications systems beyond today’s fixed and 3rd generation mobile networks. It is part of the Wireless World Initiative [2]. It aims for a new concept called Ambient Networking, to provide suitable mobile networking technology for the future mobile and wireless communications environment. Ambient Networking will provide a unified networking concept that can adapt to the very heterogeneous environment of different radio technologies and service and network environments. The approach is based on an open framework for network control functionality, which can be extended with new capabilities as well as operating over existing connectivity infrastructure, thereby avoiding adding to the growing patchwork of extensions to existing architectures. One important concept investigated within the Ambient Networks project is multi-hop access to public networks. It allows accessing an infrastructure network as the Internet or an operator network over a multi-hop relay extension that is set-up and operated by the public network operator. This scenario is also called
“infrastructure multi-hop”; other multi-hop approaches, e.g. involving other user’s terminals as relays, have significantly different trust assumptions and security requirements and are beyond the scope of this paper. Section 2 describes the reference model for the multi-hop extension underlying the security investigation. After summarizing security relevant security requirements in Section 3, security solution components are described in Section 4. Section 5 concludes the paper. 2.
MULTI-HOP RELAY EXTENDING PUBLIC NETWORKS
Multi-hop extensions to access public networks are expected to have significant impact in future generation communications due to several advantages: • A large number of relays can be deployed leading to an extended wireless coverage, reduced transmit power and thereby increased lifetime for batteryoperated user terminals. Relays can be set-up dynamically to cover temporally increased capacity demand. •
Not all relays have to be equipped with a dedicated uplink to the operator’s network or to the Internet. Multiple hops through the relay infrastructure can be used instead. There is a low burden to set-up a relay node so that they can be installed flexibly and rapidly when and where needed.
Please note that an underlying assumption is that a relay is a cheaper and less powerful device (with regard to the required software functionality) compared to non-relay device, referred as Gateway (GW) in this document. We use the term GW to denote either a link or network layer device that is located in the wired infrastructure network rather than in the multi-hop access network. The relays are dedicated nodes extending the infrastructure network being set-up and configured for this purpose. The case of using user devices as relays is beyond the scope of this paper.
existence of a AAA alike infrastructure that allows inter-domain authentication and authorization for roaming users is assumed. To prevent unauthorized users from access, enforcement for the access policy has to be provided.
AAA
NW1
AAA
GW
NW2
AAA
GW
GW Infrastructure Network
•
The relay extension have to be protected against misuse: Only authorized relays are allowed to be part of the relay extension and to interact with other relays or the infrastructure network. The exchange of signaling messages between relay nodes needs to be protected against modifications, replay, injection, eavesdropping and various types of denial of service attacks (e.g., routing state modifications). Since relay nodes might be exposed to physical threats, it is important that a single malicious relay node does not impact the security of the entire network, in particular the secure network access by users to the infrastructure network.
•
The first hop between UT and first relay has to be protected, in particular to prevent overloading of the relay extension with unauthorized traffic and to ensure that downlink traffic cannot be diverted from the correct last relay by an attacker so that it would not reach the intended user. Without first-hop protection, an attacker could perform a denial-ofservice attack by diverting downlink traffic to a wrong, far-away relay node from which the intended user would not receive downlink traffic sent from the AP to him.
4.
SOLUTION COMPONENTS SECURING THE MULTI-HOP EXTENSION
R
R R R
R
R
Relays
R
R
R
UT
UT
R
R
R
UT
UT User Terminal
Figure 1: Multi-hop extensions with intermediate relays
Figure 1 illustrates multi-hop access to a public, operator-controlled network. A user terminal UT is the node that wants to access a public network NW. For this purpose, it establishes connectivity with a gateway GW of that public network via intermediate relays R. The relays have the sole purpose to provide access to the public network to authorized users. AAA servers are involved for user authentication and authorization. These can be located local to the used network or remotely involving roaming brokers. When also relays are authenticated against an infrastructure server, this is preferably handled by an AAA server local to the infrastructure access network. In the case of multihoming, a single UT can be attached to more than one access network simultaneously. Depending on the available interface adapters at the UT, it is possible that different link layer technologies are involved. Also between relay nodes, different link layer technologies may be used. In Ambient Networks, the generic link layer (GLL) hides the heterogeneity of different link layer technologies. 3.
SECURITY REQUIREMENTS
The access security for multi-hop access to a public network should be based on the same preconditions (e.g., business and trust relations, reuse of existing security material) as the case where the public network is accessed directly without using intermediate relays. Additional security requirements have to be met to ensure that the multi-hop extension can be used only for its intended purpose, namely access to the public network. The following bullets summarize the main security requirements: • Only authorized users shall get access to the public network using the multi-hop extension. The
Securing a multi-hop access network can be challenging due to the offered design choices. The main design decisions are described that have to be taken in order to meet the requirements listed in Section 3. Solutions for a multi-hop access network can be deployed with different degrees of protection. This approach allows a trade-off between simplicity of relays needed for multi-hop extension and the required security level. The extreme and trivial case of not applying any security mechanisms on relays is not discussed in great detail as it leaves the multi-hop extension open to attacks misusing the relays for other purposes than intended. It is important to note that only the security level of protection of the multi-hop extension varies, while state-of-the-art security is provided in all cases for the actual access to the public network by an end user. This section sketches different approaches to protect multi-hop access to an infrastructure network. 4.1. Relay Protection It is worth pointing out that the aspect of securing the communication between relay nodes of the operator
network can be treated separately from the protocol interaction required between the end host UT and the network for authentication and authorization. Note that this is only true as the intermediate relays belong to the same administrative domain as the infrastructure network access provider (or if there is at least a strong trust relationship between them). Relaxing this assumption even further, whereby intermediate "relays" are itself end hosts and might want to receive some form of compensation is outside the scope of this paper. Hence, relays should authenticate and authorize themselves towards the network they provide access to. This ensures that only authorized relays can participate as relays in the multi-hop extension of a public network. When relays are enrolled and added to a network, the devices typically execute some form of a configuration or imprinting procedure to establish required keying material, information about trust anchors and other security relevant configuration information. Authentication of relays can be based in particular either on a secret key configured by the operator on all relays, on a device public-key pair that can be defined by the relay manufacturer or the operator. From the perspective of a relay, a communication attempt by another relay can at the initial phase not be distinguished from an authentication request of an end user. Therefore, the same procedures are used for the interaction between the UT towards a relay/GW and between a relays towards another relay or the GW. Authentication and authorization of a relay may, however, use secret or public key based authentication without interaction with a dedicated AAA server. Cryptographic key material is established for protecting communication between relays and between a relay and a GW. This allows secure exchange of signaling and routing data between relays and between a relay and a GW. 4.2. Multi-Hop Access Design Space The following list discusses the most important design choices that affect an overall solution for UT to network authentication and authorization: 1.
2.
Which entity should acts as a AAA client for user network access?
3.
4.
What type of enforcement should be provided? a.
Data origin authentication at the link layer or at the network layer (or both)
b.
Packet filtering (MAC or IP address filtering)
Which entity is the first IP router? a.
Relay node (e.g., first-hop relay)
b.
GW (or even a node behind the GW)
Not listed above is the question of how network discovery is solved, how the UT learns the identity of the first link layer device or the GW (if the UT needs to interact with the GW). When (4a) is combined with (1b) then the UT might has to discover the GW. Note that (3) has implications for the provided level of security since packet filtering cannot provide protection against IP address spoofing of data packets and the choice for (4) has an impact on the IP address assignment and the mobility solution. Depending on the chosen mobility solution, certain architecture and security aspects need to be considered that are, however, beyond the scope of this document. As an example, it is illustrated how the aspects listed above play an important role for an overall solution: Selecting the Access Router as a AAA client (1c) that is the first IP router in the access network (4c) in combination with cryptographic enforcement (3a) at the Access Point (2b) allows to use a multi-hop version of PANA [3] or IKEv2/IPsec [4][5]. For comparison, in a different solution the AAA client is at the first-hop relay (1a) that does not offer IP router functionality (4b/c). Enforcement is provided at the first-hop relay (2a) based on cryptographic protection (3a). This combination might call for a solution as it is offered with IEEE 802.1X/802.11i [6]. As relevant design choices affecting the security approach may change in the future or are still open during the development of the security concepts for secure multi-hop access, the approach is based on highlevel solution components that describe the required functionality without restricting it to certain design choices.
a.
Relay node (e.g., first-hop relay)
4.3. Multi-Hop Access Solution Components
b.
GW (or even a node behind the GW)
Security solution components are covering the following topics:
Where should the enforcement for user network access take place? a.
Relay node (e.g., first-hop relay)
b.
GW (or even a node behind the GW)
c.
Multiple locations
•
User–to-network Interaction Based on network access authentication and authorization between the user and the user's home network (involving the operator's network using AAA mechanisms), a secure tunnel can be established between the user terminal (UT) and the
GW at the edge of the operator network spanning over multiple relays. This tunnel provides confidentiality and integrity protection for the UT irrespective of the security of the relay network. Alternatively, the cryptographic tunnel could already be terminated at the first hop device in the multi-hop relay network. •
•
between the 1st hop relay and the GW, or on layer 3 using IKEv2 and IPsec. When the solution for secure user traffic is operating on layer 2 frames, the multiple physical relay links are hidden and appear logically as a link between the UT and the AP. The Ambient Network generic link layer can provide this abstraction. UT
Traffic filtering on relay nodes Relay nodes have to filter received frames/packets to enforce that only authorized traffic is forwarded. The intention is to ensure that the multi-hop extension can be used by UTs only for its intended purpose, namely accessing the public network. A relay has to handle user traffic between the UT and the GW in the uplink and the downlink direction, signaling traffic exchanged between relays nodes, and signaling data exchanged between yet unauthenticated nodes (either user terminals or relays) for authentication towards the public network. First hop protection It might be sufficient to rely only on the AP to perform enforcement on the data traffic. In environments with higher risk the fist-hop shall be protected, this can operate in an opportunistic manner. That is, the two peers can authenticate each other’s claimed identities to ensure that they are communicating with the same peer during a session (“sameness” property), but they have no knowledge of the trustworthiness or authorization of the other node.
R
AAA
Success
Protected User Traffic
Figure 2: User Traffic Protected between UT and GW
Disadvantages are that communication between relays, as, e.g., the exchange of signaling data between relays is not protected, and that the relay infrastructure extension is not protected against misuse. This would allow, e.g., two cooperating users to misuse the relays for free communication over the relay extension not involving the GW (filtering of user traffic is described in Section 4.3.4 below, ensuring that user traffic is forwarded only if it originates from or is targeted at the GW). 4.3.2.
Relay Authentication and Authorization
In addition to Section 4.3.1, a relay has first to be authenticated and authorized to be included in the relay extension network. R
GW
R
Authentication and Key Agreement (AKA)
No Relay Protection
In this case, the relays act merely like repeaters, forwarding all user traffic in upstream (UT? AP) and downstream (AP? UT) direction. The relays would forward frames to the next hop based on the destination MAC address. After successful user authentication and authorization for network access, security material is established to protect user traffic between the UT and the GW against manipulation (integrity) and eavesdropping (confidentiality), as shown in Figure 2. The user authentication involves communication between the GW and a backend AAA server (e.g., RADIUS or DIAMETER), whereby EAP methods is often used. The AAA server sends, as part of success message, keying material and authorization information for this session to the GW. User traffic can be protected on layer 2 by forwarding protected layer 2 frames
GW
Authentication and Key Agreement
To illustrate these solution components, some security solution approaches are sketched in the sequel of this section. The graded approaches offer different levels of protection. 4.3.1.
R
AKA
AKA
Protected Relay Traffic
Protected Relay Traffic
Protected Relay Traffic
Figure 3: Protected Relay Signaling
The establishment of long-term keying material (out-ofband, via imprinting techniques or even including the AAA infrastructure) can be used for establishing session keys to protect inter-relay and relay-GW signaling traffic as shown in Figure 3. Protection can be provided by the respective link or network layer security protocols (e.g., TKIP or CCMP, IPsec ESP). 4.3.3.
Protected Inter-Relay User Traffic
In addition to signaling traffic as described in Section 4.3.2, also user traffic can be protected by relay. This further prevents possible misuse of relay extension for
free communication: When a user inserts an invalid frame/packet in the relay infrastructure having as either source or destination the address of a valid GW, it is forwarded only after cryptographic verification, making it unusable for an adversary. For this purpose, the protected user traffic PDUs can be tunneled when forwarded by relays. This inter-relay protection can again be based on, for example TKIP, CCMP or IPsec ESP). 4.3.4.
User Traffic Filtering on Relays
In extension to Section 4.3.1, the relay infrastructure is protected against misuse to some degree by filtering of forwarded frames/packets based on source and target MAC and/or IP addresses. It can thus be verified that either the source or the destination address is the one of the GWs, preventing forwarding of traffic that is not either originating from the GW or being destined to the GW. But protection is based only on addresses that can be manipulated quite easily, and unauthorized traffic can be detected only at the GW, making the relay infrastructure susceptible to denial-of-service attacks. Some degree of DoS vulnerability is, however, unavoidable in wireless networks. An attacker who intends to misuse the relays, can still insert invalid packets, but they are forwarded only when the address of a valid GW. 4.3.5.
First-Hop User Authentication
In this case, already the 1st-hop relay authenticates the user, using a backend AAA server for user authentication. UT R
R
GW
AAA
Authentication and Key Agreement Success
Prtd. User Traffic
the required keying material to the different links. Note that when the 1st hop relay would provide the full functionality of an access point (AP), this would actually be like an AP mesh. Should the user traffic be protected additionally towards the GW, a tunnel can be established spanning the multi-hop extension. Concrete technologies would be WLAN-based access towards 1st hop relay (using 802.1X+EAP) and establishing an IPsec-based tunnel using IKEv2 between UT and AP. As a variant, the 1st hop would be protected by socalled “opportunistic security” ensuring cryptographically the “sameness” of communication partners. This means that both entities – UT and 1st hop relay – can ensure that they are communicating with the same entity during the lifetime of a session. This can be combined with actual user authentication that would then just update the policy associated with the existing security association. 5.
CONCLUSIONS
This paper presented the concept of multi-hop relay extensions to an infrastructure network set-up and operated by a public network operator. After describing a reference model, the security requirements to protect the multi-hop access infrastructure extension have been presented. Design decisions have been discussed that have an impact for a solution, and relevant security solution components have been described offering a graded, modular approach. ACKNOWLEDGMENT This paper describes work undertaken in the context of the Ambient Networks – Information Society Technologies project, which is partially funded by the Commission of the European Union. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the Ambient Networks Project. The authors would like to thank their colleagues in the Ambient Networks project for many helpful contributions, hints and discussions.
REFERENCES Figure 4: User Traffic Protected between UT and 1st Hop Relay
The established keying material for traffic protection spans only over the first hop. The disadvantage is that the first hop relay has to be trusted to a high degree as it is both responsible to enforce user network access control, and to interact with the AAA infrastructure. This makes this approach less preferred as relays are expected to be put in publicly accessible places. The relays can use keying material established between relays for inter-relay and relay-GW communication, see Section 4.1, to protect user traffic hop-by-hop (not shown in Figure 4). The security controller function of the generic link layer can provide
[1] Ambient Networks homepage, available at http://www.ambient-networks.org/ . [2] Wireless World Initiative, available at http://www.wireless-world-initiative.org/ . [3] Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin: “Protocol for Carrying Authentication for Network Access (PANA)”, IETF Draft, , work in progress, May 2005. [4] Stephen Kent, Randall Atkinson: “Security Architecture for the Internet Protocol”, RFC2401, Nov. 1998. [5] Charlie Kaufman (Ed.): “Internet Key Exchange (IKEv2) Protocol”, IETF Draft, , work in progress, Sep 2004. [6] IEEE 802.11i: “Amendment 6: Medium Access Control (MAC) Security Enhancements”, June 2004.
