Securing WiFi Roaming Authentication

From JRadius

Jump to: navigation, search

Abstract: Public Wi-Fi Local Area Networks (PWLAN) are rapidly being deployed at all types of locations including hotels, conference centers, cafes, airports, airplanes, and even in communities and homes. There many different Public Wi-Fi Service Providers (WISPs) who operate various networks around the world. Bringing these autonomous networks together to deliver a global Wi-Fi roaming network to Service Providers is often the function of PWLAN Aggregators. As Service Providers and their users roam on aggregated non-802.1X networks, user privacy and security is a real concern. Notwithstanding the threat posed by rogue hotspots, Service Providers and their users, do not have the same trust relationship with the potentially thousands of WISPs providing wireless access as they do with their select PWLAN Aggregators. Here is defined a protocol which can be used in conjunction with existing technologies to address roaming end-user privacy and enables Service Providers, with the use of a Smart-Client, to establish a secure authentication channel through a trusted PWLAN Aggregator intermediary.

Contents

The Problem

The concept of secure roaming is not novel. The use of EAP, specifically EAP-TTLS, within IEEE 802.1X, addresses user privacy and mutual authentication (between end-user and Home Service Provider). Indeed, the authors of this paper are strong believers in 802.1X for it also provides Wireless Security. However, the deployment of 802.1X networks continues to remain slow; forcing Service Providers to find alternative solutions for when a 802.1X network is not available at a hotspot location.

That is not to say that the deployment of Smart-Client enabled roaming has suffered. WISPr is a "best practices" document produced by the Wi-Fi Alliance and defines, in its Annex D, a method in which Smart-Clients can automatically log-in without the user having to interact with the WISP's default landing page. It is not surprising that such a pseudo-standard would be adopted quickly given that there is a clear market demand for transparent roaming and there are only a handful of PWLAN back-office solution providers required to implement the feature. Compare this to the many hundreds (if not thousands) of WISPs required to deploy wide-spread 802.1X networks, it is also not surprising (and unrealistic to think) that 802.1X with have sufficient penetration in the near future.

The JRadius Solution

Here we propose a procedure for secure Wi-Fi roaming whereby the Smart-Client makes a secure connection directly to the trusted PWLAN Aggregator. If the Smart-Client is unable to find the PWLAN Aggregator for the location, based on its phone-book, the location must be considered a rogue hotspot or simply miss-configured. Regardless, the Smart-Client should never reveal the user's identity until it has established the network's identity (or at least the PWLAN Aggregator's).

The Procedure

Image:Fig1.jpg Figure 1 - The Procedure

As shown in figure 1, the procedure is as follows:

  • 1. The Smart-Client makes a secure SSL connection to the roaming aggregator for the selected network (known by pre-configured "phone-book"), verifies the SSL certificate, and sends the user's NAI.
  • 2. Once the server has also (optionally) verified the client's SSL certificate and receiving the end-users NAI, the server returns the credentials (login and password) for the Smart-Client to use for authentication at the local WISP.
  • 3. The Smart-Client, over the existing SSL Proxy Control channel, will send the aggregator the RADIUS authentication protocol it wishes to use -- for home provider authentication. If the authentication protocol requires EAP Call-back, the connection will need to remain open to complete call-back functions.
  • 4. The Smart-Client sends the credentials it received from the aggregator to the WISP's back-office access controller using WISPr to gain Internet access. Of course, the login name posted to the WISP must have the appropriate realm to ensure the RADIUS requests come through the same aggregator.
  • 5. Based on the login name's realm, the WISP's back-office system will send the RADIUS authentication to the aggregator. The credentials given are authenticated based on what was provided to the Smart-Client in step 2. If the password does not match, the request is rejected. Otherwise, the aggregator prepares to forward the RADIUS authentication request to the home provider. The home provider's RADIUS server address and shared secret must be known (based on the NAI presented in step 1).
  • 6. The aggregator sends the RADIUS access request to the home provider using the authentication protocol and data payload provided by the Smart-Client. If the authentication protocol is the special EAP Call-back, Access-Challenges are sent back to the Smart-Client for response -- thereby being a proxy for the EAP communication.
  • 7. Upon successful authentication, the Access-Accept is sent back to the WISP's RADIUS server.
  • 8. The WISP responds to the WISPr authentication request and gives the Smart-Client a resulting response.
  • 9. Once the login session has started, RADIUS accounting will begin toward the aggregator.
  • 10. The aggregator must rewrite the RADIUS attributes to match those specified in the Access-Request then proxy the RADIUS to the home provider.

The Protocol

As mentioned, the Proxy Control channel between the Smart-Client and the Aggregator is secured with SSL and server side (and optionally client side) certificate verification. The protocol being within the connection is ASCII text and line-based for simplicity. All messages sent are followed by a new-line character. Any binary data being sent is BASE64 encoded within the single line.

When the Smart-Client first connects, it sends the NAI followed by a new-line in the format username@realm\n,

If the server likes the presented NAI, it will respond with the login and password the Smart-Client should use for access at the WISP. The login and password are returned on separate lines in the format UserName\nPassword\n.

The Smart-Client will now send the authentication protocol and necessary data to the Aggregator in the form of protocol:data\n, where data is BASE64 encoded binary data depending on the protocol, which is one of:

  • pap - When using PAP authentication, the data is simply the UNIX encrypted User-Password attribute.
  • chap - The data is the contents of the CHAP-Challenge and CHAP-Password attributes, as colon separated BASE64 strings.
  • mschap - The data is the contents of the MSCHAP-Challenge and MSCHAPv2-Response attributes, as colon separated BASE64 strings.
  • eap - When EAP is being used, the data is the EAP-Message. When the Aggregator receives a Access-Challenge, the EAP-Message is sent back to the Smart-Client in the same fashion. Any number of call-back challenges may occur.

PAP Example

In this example, the Smart-Client wants the Aggregator to use the legacy PAP RADIUS authentication protocol. The Smart-Client provides the contents of the PAP User-Password attribute -- all that is needed for the ultimate authentication against the Home Provider.

Image:Fig2.jpg Figure 2 - PAP Example

In figure 2, the following steps are shown:

  • 1. The Smart-Client sends the true NAI to the Aggregator.
  • 2. The Aggregator replies, should it authorize the NAI, with a one-time user-name and password combination.
  • 3. The Smart-Client sends the Aggregator instructions to use PAP authentication back to the home provider and also provides the BASE64 encoded contents of the User-Password RADIUS attribute.
  • 4. The Smart-Client proceeds to login.
  • 5. The OTP is intercepted and verified.
  • 6. The Home Provider is send the users true NAI and User-Password value.

EAP Example

Here is an example of a EAP-MD5 authentication exchange. The Home Provider's RADIUS server, in this example, is configured to use EAP-MD5 as the default. The Smart-Client instructs the Aggregator to use a EAP authentication protocol which will require the connection to the aggregator to remain active (and responsive) during actual authentication.

Image:Fig3.jpg Figure 3 - EAP Example

In figure 3, the following steps are shown:

  • 1. The Smart-Client sends the true NAI to the Aggregator.
  • 2. The Aggregator replies, should it authorize the NAI, with a one-time user-name and password combination.
  • 3. The Smart-Client sends the Aggregator the BASE64 encoded EAP-Identity.
  • 4. The Smart-Client proceeds to login.
  • 5. The OTP is intercepted and verified.
  • 6. The Home Provider is send the users true NAI and the first EAP-Message.
  • 7. The Home Provider replies with the EAP-MD5 challenge.
  • 8. The EAP-Message is proxied to the Smart-Client by the Aggregator.
  • 9. The Smart-Client processes the challenge and returns the resulting EAP-Message.
  • 10. The EAP-Message is proxied back to the Home Provider to complete the EAP-MD5 authentication.

The Implementation

The PWLAN Aggregator "Proxy Control" and RADIUS logic has been implemented utilizing the open-sourced JRadius project. JRadius is not a RADIUS server (for that we used FreeRADIUS), but is a RADIUS logic server. In which, we also implemented the SSL-based connection pool for secure Smart-Client communication.

Basic Architecture

Image:Fig4.jpg Figure 4 - Basic Architecture

The JRadius Server is configured to run a SSL Listener within its context. The listener verifies connections and queues the requests. A proxy Control Processor will dequeue the request and perform the protocol described above. Connections and the allocated one-time login names and passwords are managed within the Session Manager. The JRadius Server is also configured to run the Packet Handlers for the one-time password verification and proxy authentication.

Within JRadius, Packet Handlers are configured to handle requests at the various FreeRADIUS module entry points. For our purposes, we are interested in the following FreeRADIUS entry points:

  • authorize - Where the packet handler checks the User-Name attribute against the Session Manager to determine if it has an associated Proxy Control Session. If so, FreeRADIUS is given the password to authenticate the request.
  • post_auth - Where the packet handler, upon success (where the reply packet is Access-Accept), has the Session Manager process the true user credentials by creating a JRadius RadiusClient context.
  • preacct - Where we rewrite the RADIUS accounting and have FreeRADIUS proxy to the Home Provider.

Only during post_auth, when we know the OTP has been verified, do we authenticate the true credentials against the Home Provider. The RADIUS attributes received from the NAS in the OTP RADIUS Access-Request are copied, with some exceptions, to the Access-Request that is sent to the Home Provider. The authentication protocol specific attributes are overwritten with the appropriate attributes defined by the protocol specified by the Smart-Client. In the event the Smart-Client is using an EAP protocol, the Access-Challenge EAP-Message is sent back to the Smart-Client which has to then reply with the appropriate EAP-Message for the EAP sub-protocol being used.

Conclusion

PWLAN Aggregators need to do more than just provide roaming networks. As trusted third party intermediaries, Aggregators are in the position -- and have the opportunity, given existing pass-through address and RADIUS realm configurations -- to facilitate end-user privacy and protection with one-time credentials and authentication proxy services.

Retrieved from "http://jradius.net/wiki/index.php/Securing_WiFi_Roaming_Authentication"
Personal tools