Virtual Prepaid Tokens For WIFI Hotspots - Seminar Paper

Abstract:

With the rise of Wireless Fidelity (Wi-Fi) technology comes the rise of the hotspot - public access Wireless Local Area Networks (WLANs) that allow anyone with a Wi-Fi capable notebook or PDA to connect to the Internet or a corporate intranet in airports, hotels, coffee shops, or even campgrounds and fast food restaurants.

Billing is often cited as a problem area that contributes to low hotspot utilization. Existing billing methods, such as subscription, pay-per-use account, and prepaid tokens have drawbacks that turn away many potential users.

The virtual prepaid tokens (VPTs), a novel billing scheme that allows users to obtain access at Wi-Fi hotspots without having an account with a hotspot provider or a physical prepaid token (PPT). Upon arrival at a hotspot, a user buys a VPT online, using a third-party payment server with which the user already has an account. Recent experiments on these VPTs had shown that users can buy a VPT and gain full Internet connectivity in less than 15 seconds, i.e. much less time than it would take to create another account or to buy and activate a PPT.

VPTs can be used in hotspots that use a captive portal or 802.1x for user authentication. The 802.1x enables better security. We discuss a novel scheme that allows a single access point to support both users authenticated by captive portal and by 802.1x. Since captive-portal is being widely used for user authentication, hotspots can use this novel scheme for migrating to 802.1x without disrupting legacy captive-portal users.

Introduction:

Wi-Fi hotspots are expected to have an important role in future provisioning of “anywhere, anytime” connectivity. They are quickly being deployed at locations that tend to attract nomadic users, such as cafes, airports, hotels, and conference centers. Although hotspots have limited range, they offer lower installation costs and higher bandwidth than do competing alternatives, such as 3G wireless.                    

 Billing is often cited as a problem area that contributes to low hotspot utilization. Existing billing methods have drawbacks that turn away many potential users. Three of the most common methods are subscription, pay-per-use account, and prepaid token.

Even though subscriptions provide a steady revenue stream and the convenience of a fixed price and single monthly payment to the user, Users may be concerned about provider reliability. Instead of a subscription, users may set up a pay-peruse account with a provider. Pay-per-use accounts typically draw funds automatically from one of the user’s bank or credit card accounts, when the user gains access. Pay-per-use accounts can be less wasteful than subscriptions to sporadic users. Moreover, a user may occasionally need access in places that are not served (directly or by agreement) by any of the providers that serve areas more frequently visited by the user. In the latter cases, users may prefer prepaid tokens (PPTs). PPTs contain an id and password that are typically revealed by scratching a card and are activated after first use for a limited time. A user does not need to set up any account to buy such a token; payment may be, e.g., by cash or credit card. Prepaid tokens offer little risk to users.  In many cases (e.g., at an airport), vendor location may be inconvenient or not obvious. Moreover, a vendor location may be closed when a token is needed.

 This paper contributes an alternative billing architecture using virtual prepaid tokens (VPTs) and experimentally evaluates its performance. Users buy VPTs at the point and time of access, using a third-party online payment server. Therefore, such an account is more flexible than is a conventional pay-per-use account, which can be used only to purchase access from a specific provider or set of providers.

 The main difficulty in VPT implementation is that most current hotspot architectures authenticate a user before authorizing any Internet access by the user. VPT purchases require, however, that unauthorized users communicate with payment servers on the Internet. The VPT architecture accommodates such communication while blocking all other Internet access by unauthorized users. Communication between user and payment server is secured end-to-end by SSL.

Experiments show that users arriving at a hotspot can buy a VPT and gain full Internet connectivity in less than 15 seconds, i.e. much less time than it would take to buy and activate a physical token. VPTs can be used in hotspots that employ a captive portal or 802.1x to authenticate users. Most current hotspots use a captive portal, but 802.1x enables much better security. In particular, 802.1x enables mutual authentication between user and hotspot and encryption keys at the link layer. 

Captive portals for users with subscription, pay-per-use account, or physical

    Pre-paid token:                                                

Hotspots typically do not use WEP, Wi-Fi’s original security scheme. WEP would require matching secret keys to be manually configured in access points and user computers. Such keys would be difficult to keep secret in public settings, such as hotspots.

 Instead, hotspots usually employ captive portals for user authentication. Captive portals do not require special configuration of user computers. A special gateway between the hotspot’s LAN and the Internet enables only authorized users to communicate with the Internet. The gateway distinguishes authorized and unauthorized users by their MAC and IP addresses.

The gateway allows unauthorized user’s DHCP, ARP, and DNS query packets. Unauthorized users use DHCP to obtain networking configuration parameters. They are then expected to open a Web browser and send a Web request. The gateway redirects any Web requests from unauthorized users to a captive portal, and drops any other unauthorized packets. The captive portal returns to the user an SSL-secured login page that requests the user’s id and password, and in case of success, sends the user’s MAC and IP addresses to the gateway for authorizing the user’s Internet access. The captive portal usually also sends the user a session management page with a button for logging off, on a small popup window that is not used for browsing.

 Finally, the captive portal redirects the user to the Web page that the user initially requested. Captive portals typically communicate with a remote account database for authenticating user passwords. Any of several protocols may be used for such communication, e.g., RADIUS, LDAP, or Kerberos. In the case of physical prepaid tokens, the database would have been previously populated with temporary accounts containing user ids and passwords that match those on the tokens.  Upon first authentication of such an account’s user, the database manager calculates and updates the respective account’s expiration time.

Captive portals for users with virtual prepaid tokens:

The SSL-secured login page that the captive portal sends to the user is modified so that it contains an area where users who do not have a valid password can order a VPT. In the latter case, the user enters the respective user id and password and selects an expiration time and online payment server (OPS), possibly from among several alternatives displayed as buttons.

The captive portal reserves in the account database the entered user id. In case of success, the captive portal sends the bill to the selected OPS and redirects the user to the OPS. The gateway is modified so that it allows unauthorized users to communicate with the supported OPSs. The selected OPS authenticate the user and ask the user to confirm payment of the provider’s bill. After user confirmation, the OPS debits the bill’s amount from the user’s account and credits the same amount, minus OPS fees, to the provider’s account. If the user’s account does not carry enough balance, the OPS withdraw the bill’s amount from the user’s credit card or bank account. After crediting the provider, the OPS notify the provider’s captive portal. The captive portal establishes the user’s account in the database and sends the user’s MAC and IP addresses to the gateway for authorizing the user’s Internet access.

Captive-portal vulnerabilities and defenses:

 Although most current commercial hotspots use a captive portal for user authentication, the resulting security does not prevent theft of service. In particular, it is easy for an attacker to hijack a session of an authenticated user. The hijacker periodically sends to an authorized user deauthentication or disassociation notifications purported to come from the access point. These notifications cause the authorized user to stop transmitting. The hijacker can then use the user’s IP and MAC addresses to communicate with the Internet.

 The increasing use of personal firewalls enables a simpler attack, freeloading. Unlike hijacking, freeloading does not require special tools and can easily go undetected. A freeloader simply uses an authorized user’s MAC and IP addresses while the user continues to communicate. Freeloading would ordinarily not be expected to work reliably, because the user receives packets actually destined to the freeloader and may respond in ways that disrupt the freeloader’s communication.

For example, the standard response to a TCP packet that belongs to a connection that, from the point of view of the receiver, is closed, is to send a RST segment to the sender, thereby possibly aborting freeloaders’ connections. However, a personal firewall inhibits responses to stray packets, including RST segments.

 When both the freeloader and authorized user have personal firewalls, freeloading works reliably and can be used in collusion against the hotspot provider. Session id checking secures the session management page with SSL, associates with the page a non-persistent cookie containing a cryptographically random session id, and tags the page with a refresh directive and some period. The directive periodically causes the user’s browser to send to the captive portal a request to refresh the session management page.  The captive portal can thus detect hijacking by noticing that it has not received a correct refresh request from an authorized user for more than the refresh period. The captive portal then unauthorizes the user’s addresses.

MAC sequence number tracking detects freeloading by noticing that MAC-layer sequence numbers form more than one trend line, corresponding one to the authorized user and the remaining to freeloaders. The access point then causes the user’s MAC and IP addresses to be unauthorized. Although session id checking and MAC sequence number tracking improve the security of captive portals, 802.1x can provide a higher level of security.

 Unfortunately, 802.1x may require the installation and con-figuration of new hardware and software in user computers, and the respective standards are still in a state of flux. Because technical support at a level that most hotspots cannot provide would be necessary, hotspots cannot currently mandate use of 802.1x.

 Wi-Fi security with 802.1x:

802.1X was drafted by the IEEE to provide improved access control. It was originally developed to protect switched Ethernet hub ports, however it was soon recognized that it was applicable to 802.11b networks as well. 802.1X is a port-based access control method that enables higher layer authentication (or ULAP – Upper Layer Authentication Protocols) to occur directly between the user and the authentication server.

Port-based Access Control: Port-based access control puts access control at the edge of the network, the network access point. An 802.1X AP has two ports: a controlled port and an uncontrolled port. The uncontrolled port relays access requests and responses between the client and the authentication server. The controlled port, which enables network access, remains "open" until authentication has been successfully completed. Users who do not authenticate successfully are denied access right at the port. Privacy is also supported by port-based access control methods, since encryption keys are not passed across the access point, but are dynamically generated on the client and the authentication server independently.

1.Mutual Authentication: In mutual authentication, the client and authentication server verify each other (similar to the way users are authenticated) to prove they are legitimate network partners.

Wired network applications only require that the user be authenticated before being granted access to network services. The identity of the network is assured by the physical connection to the network directly or through the telephone network. In wireless networks, there is no physical connection to guarantee the network identity. Security in wireless networks requires that the client confirm the identity of the network to which it is associating.

Mutual authentication protects against man-in-the-middle attacks by verifying the legitimacy of the client, as well as the authentication server. Mutual authentication, based on 802.1X standards, also ensures that the access point is legitimate and not a rogue access point, because a secure channel for key exchange is established between the authentication server and the access point.

Without mutual authentication, hotspots are vulnerable to man-in-the middle attacks:

·                      the hotspot access point can be easily spoofed by portable notebooks posing as wireless access points

·                SSIDs can be easily copied and MAC addresses can be replaced, resulting in stolen credentials.

3. Extensible Authentication Protocol (EAP): 802.1X utilizes Extensible Authentication Protocol for user authentication. EAP challenge-response dialogues are sent between the client and authentication server in encapsulated EAPOL format. The access point merely relays these EAP messages between the client and an EAP-enabled authentication server (such as a RADIUS server) until an EAP success or failure message is generated, at which point it will either grant network access through the controlled port, or disconnect the user. When the authentication server has authenticated and authorized the user, dynamic session keys are assigned and forwarded to the AP. In a per-session, single sign-on, keys change often enough to prevent key cracking or passive hacking attacks.

There are a number of proprietary as well as standard EAP authentication methods that may be employed in an 802.1X architecture. For a hotspot, the most difficult part of implementing EAP is ensuring that users’ devices are equipped with any client software or certificates required for the chosen EAP method. Cisco, Microsoft, Intel, IBM and others are integrating the latest 802.1X specification into their product lines, and most users likely already have some form of EAP support in their hardware. Microsoft Windows XP operating system, for example, is enabled to support PEAP.

Supporting both users authenticated by captive portal and 802.1x:

 To support users authenticated by captive portal and 802.1x the gateway functionality necessary for captive portals is integrated into the access points. The access points keep track of the authentication state of each client. Clients are by default considered unauthorized and can communicate only using EAPOL, DHCP, ARP, DNS queries, and HTTPS with a captive portal. A clients state changes to authorized when the respective access point receives from an 802.1x authentication server or captive portal a corresponding access-accept packet. The latter packet specifies a session timeout value. After that interval has elapsed, the client’s state reverts to unauthorized. Communication between access points and 802.1x authentication servers is according to the RADIUS protocol, which includes access-accept and access-reject packets where as communication between access points and captive portals is through authenticator packets with the same format as RADIUS access-accept and access-reject packets.

 If an unauthorized client sends any HTTP or HTTPS request, the respective access point redirects the request to a captive portal. Captive portals are SSL secured and ask for and verify the client’s credentials (e.g., id and password). Captive portals and 802.1x authentication servers may use the same account database. After authenticating a client, a captive portal sends to the client’s access point an access-accept packet.

Access-accept packets may specify different filter id values according to client class (as defined in the account database) and how the client was authenticated (802.1x or captive portal). The access point can be configured to use different firewall rules or VLANs for forwarding packets from or to each authorized client, according to the client’s filter id. The access point keeps in a record each associated client’s unicast key. In the case of an 802.1x client, the access-accept packet also specifies an MS-MPPE-Send-Key and an MS-MPPE-Receive-Key. The 802.1X server includes these keys as vendor extensions in the RADIUS access-accept packet that the server sends to the authenticator when the server accepts the client. The access point uses these keys for communicating to the client a unicast and broadcast key for securing subsequent data frames. On the other hand, in the case of a captive-portal client, the unicast key is null, indicating that the access point does not encrypt, decrypt, or authenticate packets that it forwards to or from the client. This case achieves backward compatibility with the default configuration of most existing Wi-Fi NICs and access points. The access point also keeps track of the number of associated 802.1x and captive-portal clients, respectively. When the access point needs to send to its associated clients a broadcast packet, the access point sends the packet secured with the broadcast key, if there are any associated 802.1x clients; and sends the packet without security if there are any associated captive-portal supplicants (if there are both 802.1x and captive-portal supplicants, the access point sends broadcast packets twice). Commonly, the only packets that may need to be broadcast twice are DHCP and ARP. Finally, the access point’s beacon frame is set so that the Capability field’s Privacy bit is not set (some client Wi-Fi cards will not associate without static WEP if this bit is set, regardless of client configuration).

 Integrating 802.1x based security in virtual prepaid tokens:

 To enable 802.1x paying visitors, a special, well known account may be defined in the account database (e.g., an account with id “visitor”, null password, no expiration date, and a special filter id with access restrictions similar to those of unauthorized clients). This account’s dummy credentials allow an 802.1x client to obtain session keys for secure Wi-Fi communication. The client then starts a Web browser and sends a Web request. Given that the client’s rights are still those of an unauthorized client, the access point redirects the request to the captive portal. The client can then purchase a VPT with the differences that 802.1x has authenticated the hotspot to the client and link-layer encryption is used between the client and access point. After the client completes the purchase, the captive portal sends a new access-accept packet to the respective access point. The access point then changes the client’s status to authorized and upgrades the client’s access rights. This upgrade is automatic and does not require the client to input the respective id and password.

Conclusion:

Support for VPTs and simultaneous captive-portal and 802.1x authentication can be added to an access point with little extra memory, negligible overhead, and good interoperability with various clients. For occasional hotspot users, VPTs offer several advantages relative to other billing options. Unlike a subscription, VPTs do not have a monthly carrying cost. Instead of a pay-per-use account with the provider or aggregator, which can be used only to purchase access at certain hotspots, VPTs use an account with a third-party online payment server, which allows the user to employ the account for any other payments as well.Unlike physical prepaid tokens, VPTs allow a user to order and obtain Internet access from a provider in less than 15 s, even if the user has no previous or subsequent relationship with that provider or that provider’s aggregator. Simultaneous support for captive-portal and 802.1x authentication allows hotspots to provide recent Wi-Fi security improvements to those clients whose configuration supports them, without disrupting legacy clients. Improvements include mutual authentication between client and hotspot and link-layer packet encryption and authentication with dynamic per-session keys.