An Architectural Framework for Providing WLAN Roaming

Transcription

1 An Architectural Framework for Providing WLAN Roaming D.Vassis, G.Kormentzas Dept. of Information and Communication Systems Engineering University of the Aegean GR-83200, Karlovassi, GREECE s:{divas; ABSTRACT The wireless revolution in the local area networking landscape brought Wireless LAN (WLAN) technology in the foreground. In the emerging WLAN market, a significant number of different WLAN operators/providers are expected to claim its own portions. One of the basic clients demands will be the provision of wireless connections to multiple WLAN settings in different domains/hot spots (e.g., hotels, airports, corporate environments, etc.). The need for global WLAN roaming is self-evident given that a single WLAN operator/provider can not possess (or even administer) all the possible WLAN settings in which one of its client may require a wireless connection. Towards this direction, the paper discusses an architectural framework for providing WLAN roaming. The proposed framework conforms to IEEE b (Wi-Fi) standard and adopts standards-based authentication mechanisms. Implementation issues of a prototype are also discussed. KEYWORDS: Authentication, EAP, IEEE 802.1X, RADIUS, Roaming, WLAN. I. INTRODUCTION As the adoption of Wireless Local Area Networks (WLANs) is growing rapidly in both corporate environments and public spaces, the local area networking landscape is heavily reshaped. In this setting, a significant number of different WLAN Internet Service Providers (WISPs) is anticipated to emerge. The provision of secure roaming for WISPs clients can constitute an important benefit for WISPs in order to strengthen their presence in the wireless market [1]. When a wireless user wants to join a WLAN, a subscription to the corresponding WISP is required. This can mainly be achieved either by a prepaid-time card (user logs on WISP using username and password inscribed in the prepaid-time card), or a fixed account. The WLAN roaming problem concerns the fact that a wireless user subscription (through a prepaid-time card or a fixed account) is valid only to WISP in which it has been initially activated. In other words, in the current WLAN setting, when a wireless user (even if disposes a WISP subscription) desires to roam in a different WISP, a new prepaid-time card or fixed account is needed. Conforming to the IEEE b (Wi-Fi) standard [2], the paper discusses an architectural framework for roaming on WLANs. The framework adopts standards-based WLAN authentication mechanisms allowing a wireless user to move across multiple WLAN settings administered by different WISPs. The rest of the paper is organised as follows: Section 2 gives an outline of the basic WLAN authentication mechanisms that are used in the proposed roaming framework. Section 3 presents the framework and Section 4 discusses implementation issues of a prototype wireless networking setting, which is going to provide WLAN roaming according to the framework s conceptions. Finally, Section 5 concludes the paper giving also some directions for future work. II. BASIC WLAN AUTHENTICATION MECHANISMS In a WLAN networking setting, a typical authentication procedure involves three elements (see Figure 1): the wireless user under authentication, the corresponding Access Point (AP), which provides wireless access to the user and the Authentication Server, which actually performs the authentication operation. 49/1

2 Wireless User AP Authentication Server Figure 1: WLAN entities involved in an authentication procedure Typically, the authentication-purposed communication between the wireless user and the AP is achieved through the combined operation of Extensible Authentication Protocol Over LAN (EAPOL) [3] and 802.1X protocol [4], while the corresponding communication between the AP and the authentication server is based on RADIUS (Remote Authentication Dial In User Service) [5]. For achieving secure communication, the mentioned protocols make use of encryption [6] and public-key based certification [7] mechanisms. The major operational objective of IEEE 802.1X protocol is to authenticate the traffic flows running through the ports of an AP. Highlighting this operation, until the certification of the wireless user s credentials, the AP s port serving the user of the wireless terminal under authentication rejects all the user s messages except those of EAP type. When the user s credentials are certified, the port accepts any type of legal traffic. Subsequently, the authenticated user takes an IP address and obtains access to network services offered by the WLAN operator hosting the AP, which participated in the authentication process. EAPOL defines the messages (which are encapsulated in frames) needed for the communication between the wireless user and the AP during the authentication process [8]. The most significant EAPOL messages for the proposed roaming framework are: EAP-Request: Through this message, an AP requests authentication information from a wireless user. EAP-Response: A wireless user sends to an AP the requested authentication data. EAP-Success: A wireless user is informed by an AP about the success of the authentication process. EAP-Failure: A wireless user is informed by an AP about the failure of the authentication process. EAPOL-Start: An AP defines the beginning of an authentication session. EAPOL-Logoff: A wireless user informs an AP about its intention to close the session. The RADIUS messages [9, 10] are similar to those of EAP with the difference that the RADIUS messages are encapsulated in UDP messages, meaning that an IP session must pre-exist [11, 12]. The most significant RADIUS messages for the proposed roaming framework are: Access-Request: Request authentication from an AP to the RADIUS server (i.e., authentication server). Access-Accept: RADIUS server accepts the AP s request. (User s credentials are valid.) Access-Reject: RADIUS server rejects the AP s request (User s credentials are invalid.) Access-Challenge: RADIUS server requests an ΑΡ to send information concerning the credentials of a user. Accounting-Request: Αn AΡ provides accounting information to the RADIUS server and requests for accounting operations to take place. Accounting-Response: RADIUS server acknowledges the receipt of the accounting information. III. THE PROPOSED ROAMING FRAMEWORK The term WLAN Community constitutes one of the basic concepts of the proposed roaming framework. A WLAN community is created by the WISPs that are going to participate into the framework. Explicit Service Level Agreements (SLAs) define the collaboration terms (especially the accounting ones) among the participants of the community. A key module of the proposed architectural framework is a central database, which contains contact information records for all WISPs that participate in a particular WLAN community. Hereafter, we will refer to this database by the name WISP server (WISPR). WISPR can be hosted from any WISP of the WLAN 49/2

3 community, while for achieving secure communication among WISPR and WISPs a protocol such as SSL [13] can be adopted. The format of the WISPR records is given in the following figure. Name Country Code Provider Code IP Address Location 16 octets 3 octets 5 octets 4 octets 8 octets Figure 2: WISPR records Outlining the fields of a particular WISP record in WISPR, we have the following: Name: The name of WISP. Country Code: The country code of WISP. Provider Code: A code defined by WISPR. It constitutes an abbreviation of the WISP name and facilitates the WISP identification. IP address: The IP address of the RADIUS server owned by the particular WISP. It is considered that RADIUS server includes also accounting information. Location: The location of WISP. When a WISP desires to become member of the proposed roaming framework, it must upload to WISPR its RADIUS server contact information. Simultaneously, the under registration WISP retrieves the contact information of the other registered WISPs. Periodically (e.g., every day), a registered WISP informs WISPR about its current status. Both for registration and update phases, the exchanged UDP messages are shown in Figure 3. WISP Registration_Request WISPR WISP Update_Request WISPR Registration_Challenge Registration_Response Update_Retrieve Update_ACK Registration_Retrieve Registration_ACK Registration Periodic update Figure 3: Exchanged messages between WISP and WISPR Commenting on registration phase, a WISP sends a Registration_Request message to WISPR asking for registration. Through a Registration_Challenge message, WISPR asks from WISP under registration the provision of the appropriate registration record (see Figure 2). WISP provides the requested record sending a Registration_Response message to WISPR. Furthermore, WISPR informs WISP about the contact information records of all the other registered WISPs through a Registration_Retrieve message. WISP acknowledges the reception of the WISPR records sending a Registration_ACK message to WISPR. For the periodic update phase, a registered WISP periodically sends to WISPR an Update_Request message in order to retrieve new or changed WISPR records. If there are such records, WISPR provides them to WISP through an Update_Retrieve message. The process is completed though an Update_ACK message sending from WISP to WISPR. Besides the retrieved WISPR records, each WISP participating in the WLAN roaming community, keeps for its own served users the corresponding profiling information records. For each WISP, both WISPR records and user profiling records are stored in a respective local database. The format of the user profiling records is given in the following figure. 49/3

4 Country Code Provider Code User Code Password Date Registered Time Spend/ Remaining Card Username 3 Octs 8 Octs 5 Octs 32 Octs 8 Octs 8 Octs 32 Octs username Figure 4: WISP user profiling records Outlining the fields of a particular user record in the WISP local database, we have the following: Country Code and Provider Code: The same fields as in the records of WISPR database. User Code: The user code provided by WISP. Password: The user password provided by WISP. Date Registered: The date in which the user account (either a prepaid-time card, or a permanent subscription) has been activated. Time Spend/Remaining: If it refers to a permanent account, this field corresponds to the total time that the user has been connected in any of the WISPs participating in the roaming supported WLAN community. For a certain time period this field is continuously increased, while periodically (e.g., every month), it turns to zero. If the described field refers to a prepaid time-card, it corresponds to the user s WLAN connection remaining time. It is continuously decreased until the expiration of the user s prepaid connection time. Card username: If a wireless user joins a WLAN community using a prepaid-time card, it is possible that the recorded username in the card will not follow the format of username depicted in Figure 4 (i.e., Country Code Provider Code User Code). For this purpose, WISP keeps in the field Card Username the username of the card and assigns to the user (after the authentication phase) a new username conventional to the depicted format. It is assumed that the prepaid-time card is activated for the first time in a WLAN area administered by the card provider. Putting the presented concepts together, Figure 5 depicts the proposed architectural roaming framework. WLAN Community WISPR AP FISP RADIUS HISP RADIUS Registered WISPs FISP Users Registered WISPs HISP Users User WWW Figure 5: The proposed roaming framework Home ISP (HISP) refers to the WLAN provider in which the wireless user has been originally subscribed (using a prepaid time card or a fixed account). HISP includes its own RADIUS server and local database hosting WISPR records (providing contact information for the other WISPs of the WLAN community) and profiling information records for the users currently served by HISP. Analogically, Foreign ISP (FISP) concerns the remote WLAN provider in which the wireless user desires to be connected. FISP includes its own RADIUS server and local database with the corresponding records. The following subsection discusses an example operational scenario of the proposed roaming framework. The described framework actions are based on EAP and RADIUS messages that are presented in Section 2. 49/4

5 A. AN EXAMPLE SCENARIO OF ROAMING OPERATION Figure 6 demonstrates the functional operation of the proposed roaming framework in case where a registered user in a home WLAN operator (i.e., HISP) is moved to another WLAN networking setting serving by a different WLAN operator (i.e., FISP) in which the user under consideration does not have an account or a prepaid time card. The Access Point (AP) of FISP, which perceives the presence of new wireless client, commences through EAP Request messages the user authentication (the sequence of the corresponding messages is depicted in Figure 6). Receiving the client s username (parameter MyID) through the appropriate EAP Response message, AP creates and forwards to FISP RADIUS server an appropriate RADIUS Access Request message asking for client authentication. FISP RADIUS server checks the client s username (MyID) and finds out the corresponding HISP code. Subsequently, it checks its local database containing WISPs contact information (updated frequently from WISPR) and retrieves the IP address of HISP RADIUS server. Subsequently, FISP RADIUS server sends to HISP RADIUS server a RADIUS Access Request message requesting authentication and accounting information for the examined client. HISP RADIUS server asks the client s password through a RADIUS Access Challenge message, which is firstly transmitted to FISP RADIUS server, then it passes to the appropriate AP and finally it reaches as an EAP Request message to the client. The client responds to the password request and sends it firstly to the corresponding AP as an EAP Response message (parameter OTPpw). AP creates the respective RADIUS Access Request message and forwards it to FISP RADIUS server, which in its turn it forwards the RADIUS Access Request message to HISP RADIUS server. The latter checks the client s credentials and either accept or reject the client. For a successful authentication process (as in our case depicted in Figure 6), the HISP RADIUS server sends a RADIUS Access Accept message to FISP RADIUS server, which delivers it to the appropriate AP. The latter informs the client about its successful authentication through an EAP Success message. Client AP FISP HISP EAP Request Auth ACK EAP Auth EAP Request Identity EAP Response (MyID) Access Request/ EAP Message/ EAP Response(MyID) Access Request/ EAP Message/ EAP Response (MyID) EAP-Request OTP/OTP Challenge Access Challenge/ EAP-Message/ EAP-Request OTP/OTP Challenge Access Challenge/ EAP-Message/ EAP-Request OTP/OTP Challenge EAP Response/ OTP, OTPpw Access Request/ EAP-Message/ EAP-Response OTPpw Access Request/ EAP-Message/ EAP-Response OTPpw EAP Success Access Accept/ EAP Message/ EAP Success Access Accept/ EAP Message/ EAP Success Figure 6: Exchanged messages for roaming 49/5

6 After the successful client authentication, FISP RADIUS server records the time the user remains connected. When the user asks to log off, FISP RADIUS server informs HISP RADIUS server about the log off and the time the client remained connected to its own network. Based on this information and the corresponding SLAs (Service Level Agreements) between the WISPs, the appropriate charging operations can be performed. In case where the user owns a prepaid-time card, FISP RADIUS server disconnects the user when its available time (known from the time remaining field of the corresponding record in the FISP database keeping the users under service) expires. The exchanged messages for log off are depicted in Figure 8. The client sends an EAP LOGOFF message to the corresponding AP informing it about its intention to log off. AP sends the corresponding RADIUS Accounting Request message to the FISP RADIUS server, which forwards it to the HISP RADIUS server. The latter performs the necessary accounting operations in order the user s account to be charged appropriately and sends a RADIUS Accounting Response message to FISP RADIUS Server, which passes it to AP completing in this way the log off process. Client AP FISP HISP EAP LOGOFF Accounting Request Accounting Request Accounting Response Accounting Response Figure 7: Exchanged messages for log off IV. AN IMPLEMENTED PROTOTYPE A prototype of the proposed roaming framework is under development. The prototype targets to include a WLAN community hosting two virtual WLAN providers, each one consisting of an AP and a RADIUS server. The two RADIUS servers (emulating the roles of HISP and FISP RADIUS servers) and the prototype s WISPR server will be statically interconnected in a wired Ethernet topology. Among the variety of RADIUS servers that have been developed by several vendors, the prototype under implementation will adopt the open source FreeRadius RADIUS server [14], which runs both on Windows and LINUX operating platforms. It is planned that FreeRadius will be installed without any software changes in the APs (running Windows XP) of the prototype [15, 16]. Some software modifications (according to the design guidelines of the previous section) are anticipated for the installation of FreeRadius in the HISP and FISP servers. Specifically, the states transition diagrams of Figures 8-10 will be implemented. EAP Logoff AUTHENTICATED Access Accept Access Reject DISCONNECTED CONNECTING AUTHENTICATING (Access Reject && reauthcount = reauthmax) EAP Logoff Figure 8: States transition diagram for AP 49/6

7 ACCOUNTING Accounting Request UNAUTH/ED Access Request AUTH/TING Access Accept AUTH/ED Access Reject Figure 9: States transition diagram for FISP ACCOUNTING Accounting Request UNAUTH/TED Access Request AUTH/TING Usern/Passwd Valid AUTH/ED Usern/passwd Invalid Figure 10: States transition diagram for HISP The 802.1X protocol will be implemented without any software changes. The fact that Windows XP operating platform (planned to run on both the APs and the wireless clients of the prototype) support it [17] will heavily facilitate the protocol implementation. Mysql database [18] will be used for the WISPR implementation. The exchanged messages between WISPR and HISP/FISP (described in the previous section) will constitute the basis for the implementation of the WISPR transactions. V. CONCLUSIONS Given that currently there is no established standard or industry practice for WLAN roaming, the paper proposes a simple architectural framework for roaming on WLANs. The proposed framework conforms to IEEE b (Wi-Fi) standard and adopts standards-based authentication mechanisms. Specifically, the EAP/802.1X protocol is used without any modifications, while a short expansion of RADIUS protocol is required. A prototype of the proposed roaming framework is under development and is expected to be finalised in the near future. The prototype will validate both the functionality and the efficiency of the proposed framework. Another future direction of this work will concern the comparison of the discussed roaming framework with other similar undergoing activities performed by WECA (creator of WiFi standard), IETF, and 3GPP. VI. REFERENCES [1] VeriSign Inc, Secure Global Roaming for WLANs, [2] IEEE IEEE Standard for Information Technology Telecommunications and information exchange between systems-local and metropolitan area networks-specific requirements- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification, /7

8 [3] L.Blunk, and J.Vollbrecht, PPP Extensible Authentication Protocol (EAP), RFC 2284, IETF, March [4] IEEE 802.1X, IEEE Standard for Local and Metropolitan Area Networks-Part 1X: Port Based Network Access Control, [5] C. Rigney, S. Willens, A. Rubens and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, IETF, June [6] R.Rivest, The MD5 Message Digest Algorithm, RFC 1321, IETF, April [7] C.Adams and S.Farrell, Internet X.509 Public Key Infrastracture Certificate Management Protocols, RFC 2510, IETF, March [8] D.Aboda, D.Simon, PPP EAP TLS Authentication Protocol, RFC 2716, IETF, October [9] C. Rigney, "RADIUS Accounting", RFC 2866, IETF, June [10] C. Rigney, W. Willats and P. Calhoun, "RADIUS Extensions", RFC 2869, IETF, June [11] S. Kent and R. Atkinson. IP Authentication Header. RFC 2402, IETF, Nov [12] S. Kent and R. Atkinson. IP Encapsulation Security Payload. RFC 2406, IETF, Nov [13] A. Frier, P. Karlton, and P. Kocher, The SSL 3.0 Protocol Version 3.0, Information available in [14] Free Radius RADIUS server. Information available in [15] K. Rosen, HOWTO: Setup for FreeRADIUS and windows XP supplicant, April [16] A. Sulmicki, HOWTO on EAP/TLS authentication between FreeRadius and WindowsXP, April [17] J. Davies, Enterprise Deployment of IEEE Using WindowsXP and Windows2000 Internet Authentication Service, Microsoft Corporation, March [18] Mysql Database, Information available in 49/8