Version 3 (modified by rnissley@…, 16 years ago)

minor grammatical/clarity edits

Original author: Benoit Grégoire, last modified:

Error: Failed to load processor Timestamp
No macro or processor named 'Timestamp' found

What is RADIUS and current support in wifidog

 RADIUS (Remote Authentication Dial In User Service) is the industry standard for sharing user network access control information. As WiFiDog was not originally designed to manually manage users. Users were meant to self-subscribe, to be computer validated and for a computer to enforce abuse-control policies. Most organizations that the core developers belong to still don't have a need for it.

However several new users of wifidog not only want to human-verify users, but also have existing userbases in RADIUS.

Luckily,  IDRC (The canadian government's International Development Research Centre) paid for Technologie Coeus inc to write a RADIUS authenticator as a proof of concept. It's based on the  PEAR Auth_RADIUS package.

  • The good news is that it supports all the features of Auth_RADIUS.
  • The bad news is that it only supports the features of Auth_RADIUS.

With these limitations, the RADIUS authenticator should probably only be used by organizations that either:

  • Already have a userbase in a RADIUS server
  • Want to manually subscribe and validate users (this is temporary, as wifidog will get a user manager before 1.0).

In other words, currently, using RADIUS to authenticate has little advantages over the internal authenticator beyond allowing you to use RADIUS.

Technically however RADIUS could be used for several purposes in Wifidog:

Allowing the auth server to authenticate against an existing RADIUS server

This is already supported, but support is limited.

  • Only authentication and accounting is supported
  • There is no bootstrap code to allow the super-administrator to be a standard radius user. So you must keep a local network with the standard authenticator (it can be made read-only) or you must set up your network with the standard authenticator, then change the authenticator to be RADIUS and then manually add the appropriate RADIUS user(s) to the admin list in the database.

The first step to more extensive RADIUS support in wifidog is to move directly to  PECL::RADIUS PHP package instead of Auth_Radius.

Allowing the wifidog gateway to directly talk to a standard RADIUS authentication server

We are very much aware that some people want us to do this, but the short answer is that it is unlikely to ever happen. But the wifidog gateway design (and the main reason for its success and reuse) is that it's the captive portal equivalent of a dumb terminal. It was explicitly designed to get rid of all the crypto dependencies (have the server insure security) and move the login and portal UI to the server.

If you want to only display a disclaimer page with no central server, you should either

  • Use NoCatSplash (or possibly other captive portals) designed for this.
  • Help write a tiny, splash only auth server that can run directly on your gateway (probaly as a bash CGI script). This is actually very easy to do, and fits perfectly well in the wifidog design philosophy. The wifidog project would be very open in making this an official part of the project.

Using RADIUS as the gateway-auth-server protocol

It would actually make sense to do this, as RADIUS and it's various standardized extensions allow communicating most of the things we want to communicate with the gateway (and has standard ways to be extended to support what it doesn't have). Unfortunately, this will have a few very practical problems:

  • We wouldn't use RADIUS to actually authenticate the user credentials, so this will clash with most's people's common conception of what RADIUS is, possibly negating the advantages of using a standard protocol.
  • It may lead people to think (or repeatedly demand) that Wifidog gateway is compatible with any standard RADIUS server, which would be a tech support nightmare.

It _may_ happen when we work on version 2.0 of the Wifidog gateway, which will have a new protocol

Using RADIUS to allow Wifidog auth server to communicate among each other

Many wireless communities want to be able to accept users from each other. As this is almost exactly what RADIUS was designed for, and is THE industry standard, on the surface, doing anything else makes little sense. This is basically allowing the Wifidog auth server to serve as a RADIUS server. Unfortunately, this would be very difficult as the auth server is written in PHP. That means two equally unattractive options:

  • Code support for the RADIUS protocol completely in PHP all the way up from the low level PHP socket functions
  • Code support as a C PHP package, which would in practice mean people would have to compile their own PHP to use it, which doesn't seem likely.

Neither of these solves the quirky problem of running PHP code as long-term listeners.

But the entire problem is only caused by the fact that a RADIUS listener is difficult to implement on a PHP web server. RADIUS is a stateless, request-response protocol like http. So the problem can be sidestepped by mechanically packaging RADIUS requests as XML documents or directly as text over https and sending responses the same way, skipping the whole complexity, and allowing support for a future "real" radius server (all the code would be compatible).

What about WISPr

WISPr (Wireless Internet Service Project Roaming) is a standard from the  Wi-Fi Alliance. It's actually a very well written standard (at least as standards go). However, the Wi-Fi alliance is making extra hard to actually get to it. Searching for "wispr" on their web site doesn't return any results, and while you can buy other Wi-Fi Alliance specs, you can't buy the WISPr one. You can still  get the WISPr specification, but it looks like an oversight and it probably can't be legally redistributed.

The main focus of WISPr is to share the necessary information to allow roaming between commercial WISPs (remote billing, etc).

It basically describes 3 things of possible relevance to WiFiDog:

RADIUS attribute support (chapter 5)

Which RADIUS attributes to use to in the WISP sharing scenario. While most's users usage of WiFiDog is quite different, many of those still apply (slightly differently) to most community group's usage. This will be most usefull if we use RADIUS for Wifidog federation.

Re-Authenticating using PANA (Appendix B)

This approach (which is basically what NoCat did) has been rejected in the WifiDog design phase, for three reasons:

  • It's a nightmare for the user (must keep java or javascript open all the time, and your device must support it)
  • Security wise, five minute is still plenty of time to do something malicious and "frame" another user.
  • It's also more than enough to attack a network (should someone be stupid enough to use captive portal technology to actually secure a non-DMZ part of a corporate network).
  • For community groups (the primary constituency), artificially inflating a user's usage of the network to maliciously run up his bill is not an issue (12h at 0$/hour is still 0...)

The smart Client to Access Gateway Interface Protocol (Appendix D)

This is basically a way for a device to potentially script the login process for portable devices (WiFi? SIP Phones, WiFi? Digital Cameras, Nintendo DSs, standalone instant messengers, etc). Should this get widespread industry support, it's one way to solve the problem of supporting devices with no web browser. It's actually quite demanding for manufacturer to implement (hence probably not the best solution), but very easy for WiFiDog to support.

What about supporting WPA?

There has been some recently renewed interest in supporting WPA with Wifidog. Let's first answer the most basic question, is it worth doing WPA in (or more exactly with) Wifidog?

Yes, to the extent that the users could STILL be splashed the portal page, even when authenticated with WPA. Remember that the primary goal of the Wifidog project is to be a location-aware captive portal, not an authenticator. Respecting the basic premise of "as little as possible on the gateway side", there are still a few possible approaches (some depend on the way we implement RADIUS above). I can see two that are most likely:

  1. Write an OpenRADIUS authorization module to allow it to authenticate against a Wifidog auth server. Then the auth server knows that a client is already authenticated over RADIUS, and skip the login page.
    • Advantages
      • Requires no modification of the gateway
      • Uses standard software whose primary job it is to support WPA and RADIUS well.
    • Drawbacks
      • Requires a separate, completely redundant RADIUS server
      • Requires the client to have a web browser to trigger the standard wifidog auth exchange with the server.
  2. Write a simple RADIUS forwarder as a Wifidog gateway plugin. The forwarder would listen on radius, and re-transmit the messages over http to the auth server. The gateway can peek at the RADIUS responses to know if the client has already been authenticated.
    • Advantages
      • Does not require a separate RADIUS server
      • Would work with WPA client with no web browser
    • Drawbacks
      • Requires writing part of the radius transport protocol on the gateway side (re-inventing the wheel)

This only makes sense if we want to reuse the "RADIUS over XML or text" code we may write to allow Wifidog auth server to talk to each other.