An Architectural Framework for Providing WLAN Roaming D

An Architectural Framework for Providing WLAN Roaming D. Vassis G. Kormentzas Dept. of Information and Communication Systems Engineering University of the Aegean Greece HET-NETs '03

Background Information • The adoption of Wireless Local Area Networks (WLANs) is growing rapidly in both corporate environments and public spaces. • A significant number of different WLAN Internet Service Providers (WISPs) is anticipated to emerge in this setting. • 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. HETNETs’ 03, Ilkley, UK, July 2003 2

Setting the WLAN Roaming Problem • 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, or a fixed account. • The WLAN roaming problem concerns the fact that a wireless user subscription is valid only to WISP in which it has been initially activated. • Conforming to the IEEE 802. 11 b (Wi-Fi) standard, 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. HETNETs’ 03, Ilkley, UK, July 2003 3

Outline of the Presentation • • Basic WLAN authentication mechanisms The proposed roaming framework Implementation issues of a prototype Conclusions & Future work HETNETs’ 03, Ilkley, UK, July 2003 4

WLAN Authentication Mechanisms Authentication Server Wireless User AP EAP/802. 1 X RADIUS • EAP (Extensible Authentication Protocol) over 802. 1 X – 802. 1 X provides port authorisation – EAP messages are encapsulated in 802. 11 frames • RADIUS (Remote Authentication Dial In User Service) – Similar to EAP process – RADIUS messages are encapsulated in UDP messages, an IP session is required HETNETs’ 03, Ilkley, UK, July 2003 5

The Proposed Framework WLAN Community WISPR AP FISP RADIUS HISP RADIUS Registered WISPs FISP Users User • • Registered WISPs HISP Users WWW WLAN community: The group of WISPs, which are going to participate into the framework. WISPR (WISP serve. R): A central database, which contains contact information records for all WISPs that participate in a particular WLAN community. Home ISP (HISP): The WLAN provider in which the wireless user has been originally subscribed. HISP includes its own RADIUS server and local database hosting WISPR records and profiling information records for the users currently served by HISP. Foreign ISP (FISP): 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. HETNETs’ 03, Ilkley, UK, July 2003 6

WISPR • WISPs must somehow know contact information for each other in order AAA procedures to be performed. • WISPR provides credential information for all WISPs of a WLAN community – 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. – A registered WISP receives new WISPR records. HETNETs’ 03, Ilkley, UK, July 2003 7

Communication between WISP and WISPR Registration_Request Registration_Challenge WISPR WISP Update_Request Update_Retrieve Registration_Response Update_ACK Registration_Retrieve Registration_ACK Registration Periodic update HETNETs’ 03, Ilkley, UK, July 2003 8

WISPR Database record Name 16 octets Country Code 3 octets Provider Code IP Address Location 4 octets 8 octets 5 octets 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 HETNETs’ 03, Ilkley, UK, July 2003 9

WISP user profiling record Country Code Provider Code User Code Password 3 Octs 8 Octs 5 Octs 32 Octs Date Registered 8 Octs Time Spend/ Remaining 8 Octs Card Username 32 Octs username • 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. HETNETs’ 03, Ilkley, UK, July 2003 10

WISP user profiling record 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: The total time that the user has been connected in any of the WISPs participating in the roaming supported WLAN community or the user’s WLAN connection remaining time. Card username: If the recorded username in the card does not follow the format of the adopted username, WISP keeps in the field Card Username the username of the card and assigns to the user a new username conventional to the defined format. HETNETs’ 03, Ilkley, UK, July 2003 11

An Example scenario of Roaming Operation • When a user roams to a FISP and requests authentication: – FISP checks the provider code from the user’s username. If it is not its own, it redirects the authentication request to the corresponding HISP. • Extension of the RADIUS protocol is required for this purpose – At the end of the session HISP performs accounting operations according to the information of FISP and the value of the field “Time spend/Remaining”. HETNETs’ 03, Ilkley, UK, July 2003 12

An Example scenario of Roaming Operation EAP Request Auth EAP Request Identity Access Request/ EAP Message/ EAP Response(My. ID) EAP-Request OTP/OTP Challenge Access Challenge/ EAP-Message/ EAP-Request OTP/OTP Challenge Access Request/ EAP-Message/ EAP-Response OTPpw EAP Response/ OTP, OTPpw Access Accept/ EAP Message/ EAP Success Access Request/ EAP Message/ EAP Response (My. ID) Access Challenge/ EAP-Message/ EAP-Request OTP/OTP Challenge Access Request/ EAP-Message/ EAP-Response OTPpw Access Accept/ EAP Message/ EAP Success HETNETs’ 03, Ilkley, UK, July 2003 13

An Example scenario of Roaming Operation (Log off) Client AP FISP HISP EAP LOGOFF Accounting Request Accounting Response HETNETs’ 03, Ilkley, UK, July 2003 14

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 Free. Radius RADIUS server. It is planned that Free. Radius will be installed without any software changes in the APs of the prototype. Software modifications (according to the design guidelines) are anticipated for the installation of Free. Radius in the HISP and FISP servers. • The 802. 1 X protocol will be implemented without any software changes. • Mysql database will be used for the WISPR implementation. HETNETs’ 03, Ilkley, UK, July 2003 15

Conclusions & Future Work • 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 802. 11 b (Wi. Fi) standard and adopts standards-based authentication mechanisms. • 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. Future Work • Comparison of the discussed roaming framework with other similar undergoing activities performed by WECA (creator of Wi. Fi standard), IETF, and 3 GPP. HETNETs’ 03, Ilkley, UK, July 2003 16