Authentication and Security in IP based Multi Hop Networks

Transcription

1 7TH WWRF MEETING IN EINDHOVEN, THE NETHERLANDS 3RD - 4TH DECEMBER Authentication and Security in IP based Multi Hop Networks Frank Fitzek, Andreas Köpsel, Patrick Seeling Abstract Network security and authentication are very important for all kinds of communication networks to assure network stability and to avoid subscription fraud. In the last years even for wireless local area networks mechanisms have been found to support both in a cellular network. In multi hop networks based on IEEE802.11, security and authentication are still open issues. Mainly the low price of the network infrastructure makes this kind of networks vulnerable. Within the scope of this paper we describe the application of IEEE in combination with UMTS Authentication and Key Agreement (AKA) to enable authentication and security in multi hop networks. keywords: IP security,, multi hop, ad hoc, TLS, WEP, EAP, PEAP, EAPoL, UMTS AKA I. INTRODUCTION In all kinds of communication systems, authentication and security have always been an important issue. Especially for wireless communications with low infrastructure costs such as wireless local area networks (WLANs), where the signals are transmitted over a wide area (not knowing about frontiers or building borders) authentication and security is crucial. Authentication in WLANs based on IEEE can be done through an access control list. All MAC addresses that are allowed to access the network via an access point are stored in this list. The MAC addresses are hard coded on the RF cards. The problem of this approach is based on the fact that not the customer, but the MAC address on the RF card is authenticated. In this case, any other person may access the network if he is in possession of the card. This unauthorized access is available until the real owner knows about the stolen card and the MAC address is deleted from the access control list. Furthermore, this authentication mechanism entails a large administration complexity, which is not negligible for a closed user group such as an office, but will be dramatically in publicly accessable networks (even more if we focus on multi hop networks). Another possibility (and this is even more critical) to get access for an unauthorized person is to spoof MAC addresses. In a case where a hacker knows the MAC address, it is possible for him to make any card look like an authorized card. For this action, a good knowledge of programming is necessary, but in this case the unauthorized access is very hard to detect in comparison to a stolen card. Further technologies such as Wired Encryption Privacy (WEP) which is based on shared keys has also some shortcomings and is not considered as useful solution to the problem of security in wireless environments [7]. A. IEEE Therefore new mechanisms were found to support authentication and security. IEEE [9] is part of the IEEE802.1 standard family that defines management functionality for IEEE802 based networks. Designed for securing wired and also wireless networks like the IEEE802.11, the WLAN standard defines a generic framework that is able to use different authentication mechanisms without implementing these mechanisms outside the back-end authentication infrastructure and the client devices. Independence of individual authentication methods is achieved by utilizing the Extensible Authentication Protocol (EAP) [5] that defines a generic container to convey authentication method PDUs. EAP messages are exchanged on the air interface between the mobile device (known as supplicant in terminology) and base station (authenticator) by using an encapsulating protocol (EAP over LAN/EAPoL). On client side, is already available in the WindowsXP operating system. Additionally, acticom offers the client support for BSD style operating systems (including MacOS X, OpenBSD), Linux operating systems, Windows 98/2000/ME, and portability to any Un*x operating system. acticom GmbH mobile networks; R & D Group; Am Borsigturm 42; Berlin; Germany [fitzek koepsel seeling]@acticom.de

2 7TH WWRF MEETING IN EINDHOVEN, THE NETHERLANDS 3RD - 4TH DECEMBER Client Network Access Server / NAS RADIUS Server supplicant authenticator backend auth server Ethernet EAPoL EAP EAP Payload CRC IP UDP RADIUS EAP EAP Payload Fig. 1 INTERACTION OF SUPPLICANT, AUTHENTICATOR AND BACKEND AUTHENTICATION SERVER AND BLOCKING DEVICE. B. Security protocols on top of IEEE Although defining an authentication framework, IEEE does not specify encryption, message integrity checking, or message authentication by itself, but sustains on an underlying secure communication channel. In wireless environments offering public access, an encryption of the air interface might not be available when processing the authentication exchange. This is true especially for WLAN systems where a shared key between client and base station is required to run Wired Equivalent Privacy (WEP). Care must be taken to secure the authentication phase in. A reasonable solution is the integration of Transport Layer Security (TLS) resulting in EAP TLS as specified in [2]. TLS [6] is the IETF successor to the Secure Socket Layer (SSL) technology and was defined to prevent eavesdropping, replay attack detection and message tampering offering protection to the authentication process. TLS uses public key cryptography to provide mutual authentication and secure data exchange. However, TLS demands special requirements on network operators when deploying certificates to customers and network access systems. To overcome these problems that arise from certificate management, an extension to EAP TLS was suggested: Protected EAP. PEAP uses the TLS handshake solely for identifying the network to a client device thus abandoning the need of assigning signed certificates to individual client devices. Client authentication is done inside the established TLS tunnel, profiting from the benefits of TLS communication. Any EAP based authentication method might be used inside the established secure channel. Figure 1 shows the interaction of supplicant, authenticator and back-end authentication server and blocking device with the various authentication and security protocols for a cellular approach. UMTS Authentication and Key Agreement (UMTS AKA) specified in [1] is mainly based on a challenge response mechanism, and in contrast to GSM AKA it enables mutual authentication. UMTS AKA works in the following manner: As given in Figure 2, the mobile terminal and the home environment agree on a secret key identifying the terminal. Whenever a Visitor Location Register (VLR) or Serving GPRS Support Node (SGSN) wants to authenticate the terminal, they convey a request of authentication data to the HLR. The HLR computes a set of authentication vectors and sent it back to the VLR/SGSN. After this exchange, the VLR/SGSN sends an authentication request to the terminal, including the Random Challenge (RAND) and the Authentication Token (AUTN). With this information and its private key (only now to this terminal and the home network), the terminal knows that this message was produced by the home network and retransmits the authentication response. By means of this information exchange the terminal is able to compute confidentiality key (CK) and integrity key (IK), while the VLR selects a CK and an IK. A specification of the EAP mechanism to distribute these authentication keys by the means of UMTS AKA is given in [4]. The authors of [4] write that the combination of AKA and EAP enables new applications such as (i) secure PPP authentication for devices with a User Services Identity Module (USIM), (ii) relaying on AKA and the network with any other device that use also EAP, and finally (iii) the usage of 3G authentication capabilities in wireless LANs with IEEE extensions [9]. The last application (iii) is used within the scope of this document. Interested readers are referred to the following documents for further informations [10], [12], [1], [4].

3 7TH WWRF MEETING IN EINDHOVEN, THE NETHERLANDS 3RD - 4TH DECEMBER Terminal NodeB RNC VLR/SGSN HLR authentication request authentication response user authentication request (RAND AUTH) user authentication response (RES) CK and IK computed CK and IK selected Fig. 2 UMTS AUTHENTICATION AND KEY AGREEMENT UMTS AKA. II. AUTHENTICATION AND SECURITY FOR MULTI HOP NETWORKS For our approach, we assume that we have an IEEE enabled access point with fixed connection to the Internet. This access point is under the control of the network provider and can be seen as the access to the home network. A subset of the wireless and mobile terminals can transmit directly to the access point. Other terminals may use the multi hop capability of terminals or virtual access points (VAP) [11], [8] which are already connected to the home network. Within the provider s network an AAA server exists. The main problem that arises in multi hop networks in terms of security is the authentication process. The authentication of nodes is not only important for the customer to avoid subscription fraud, but even for the network itself. The source of a packet has to be clearly identified to avoid the situation of hacked routing messages (hacker attack to destroy routing lists). This is even true for the DNS service, the DCHP service, and to avoid denial of service attacks. The question arises, how a client achieves a valid shared secret key and how long is this key valid. Furthermore, how can the key be transported over a multi hop network in a secure manner? For the following example, we assume that we have one access point with a wired connection and an already established and secure multi hop network as given in Figure 3. The wireless terminals in the multi hop network can either be virtual access points or other customers that are connected to the multi hop network. For illustration purpose, we assume that we have already a group of authenticated terminals or/and virtual access points. Now a new client comes to the network without direct connectivity to the access point with wired Internet connection. The -EAP framework described above is then used for the exchange of authentication data. Each supplicant of the multi hop network using the mechanism has to be able to deal with multiple server responses, because each authenticated client works as a virtual access point. On top of the EAP, we advocate to use UMTS AKA instead of PEAP or TLS/TTLS. Using UMTS AKA the authenticating client or virtual access point shall not know the secret user keys of the new arrived client. Simultaneously, the transportation of encapsulated frames over the multi hop network has to be avoided. Therefore the new non authenticated client (supplicant) passes its client ID to the authenticating client (authenticator). The authenticator (using his secure communication channel) connects to the AAA of the provider, asking a set of authentication data as described above for UMTS AKA. With this authentication data (auth-challenge/response), the authenticator is able to authenticate the supplicant using UMTS AKA-over-EAP without knowing the supplicant s ID or password. While the authentication is in process, the authenticator receives the Chal-Resp-Block. The Chal- Resp-Block allows to generate a shared secret key between provider network and supplicant. The shared secret key

4 7TH WWRF MEETING IN EINDHOVEN, THE NETHERLANDS 3RD - 4TH DECEMBER is not known to any of the authenticated clients, but only to the supplicant and the provider. At the same time, the supplicant needs shared secret keys to sign packets for Routing/DNS/DHCP known to all authenticated clients. After this procedure the new client is authenticated and he can use the classical DCHP service and authenticate packets belonging to the network in a secure manner. This approach is more suited as a simple distribution of pre shared TLS certificates. In case one virtual access point get stolen the ID and password are simply deleted in the centralized AAA server without using revocation lists. This helps to keep the administration complexity low. After having authenticated a user, privacy has to be assured. For communication between the provider network and the client, the shared secret key from the authentication process is used. By means of this procedure not even other authenticated wireless terminals can listen to the communication. For the communication between two wireless terminals within the same multi hop network, two possibilities exist. Obviously, the first is to communicate using the access point, but this would be not bandwidth efficient. For a direct communication (even over other multiple wireless terminals), a mechanism has to be found to generate a new secret key, because the keys for the communication with the access point are different. New Client Clients Clients Client UMTS AKA VAP AP AAA authenticated Fig. 3 MULTI HOP NETWORK WITH VAPS AND THE USED AUTHENTICATION AND SECURITY PROTOCOLS. III. CONCLUSION We advocate the use of IEEE EAP and UMTS AKA for authentication and security in multi hop networks. By means of an example we have shown a possible authentication process within a multi hop network. In our future work we will build up a test bed to show the feasibility of our approach using acticom s security stack [3]. REFERENCES [1] 3rd Generation Partnership Project. Security Architecture. 3GPP, June Release 5. 2 [2] B. Aboba and D. Simon. PPP EAP TLS Authentication Protocol. IETF RFC 2716, October [3] acticom. IEEE Wireless Authentication Module, [4] J. Arkko and H. Haverinen. EAP AKA Authentication. IETF, December [5] L. Blunk and J. Vollbrecht. PPP Extensible Authentication Protocol (EAP). IETF RFC 2284, March [6] T. Dierks and C. Allen. The TLS Protocol Version 1.0. IETF RFC 2246, January [7] Ericsson. Introduction of IEEE Security. 3GPP TSG SA WG3 Security, July

5 7TH WWRF MEETING IN EINDHOVEN, THE NETHERLANDS 3RD - 4TH DECEMBER [8] F.H.P. Fitzek, P. Seeling, and M. Reisslein. Reference Models and Related Business Cases for Ad-Hoc Networks. In In Proceedings of Wireless World Research Forum 6 (WWRF6) Section WG4 Section WG4, June London. 3 [9] IEEE802. Standards for Local and Metropolitan Area Networks: Port-Based Network Access Control. IEEE 802.1X-2001, March , 2 [10] G. M. Koien. An evolved UMTS Network Domain Security Architecture. Technical Report N28/2002, Telenor, September [11] S. Krco, B. Hunt, and F.H.P. Fitzek. WhitePaper on Ad Hoc networks. In In Proceedings of Wireless World Research Forum 6 WG4, June [12] Nokia. UMTS AKA in SIP. 3GPP TSG WG3 Security - S3 14, August