[isf-wifidog] WISPr and RADIUS (and MAC authentication)

[wlan at mac.com]

Hello,

I'm in the process of merging the changes noted below (also  
summarized w/ old patches here: http://dev.coova.org/wifidog.html)  
with the current SVN tree (rev 1247). The gateway logout url support  
was already added to the SVN and there were other conflicts.

Additionally, I have a working MAC address authentication  
implementation (changes in gateway and portal) using RADIUS. And more  
fixups (session-time was not calculated well) in the RADIUS  
authenticator.

For MAC auth, I am using pcap to sniff DHCP replies off the wire.  
When seen, and the client is not already on-line, the gateway will  
user the MAC as username and password and post to the login script.  
The feature is only activated in the gateway when a configuration  
option (I called MacAuthRealm) is set. The "realm" is added by the  
gateway to the username (as in "realm/<mac address>") before sending  
to the portal's login script. This realm is then used (as the  
"network" name) to find the appropriate network authenticator --  
tested with AuthenticatorRadius.

Some additional features on my mind:
- Adding a checksum url parameter to ensure no tampering of the  
initial redirect url and status updates (using a secret shared  
between gateway and portal)
- Creating a WiFiDog RADIUS vendor specific attribute to indicate the  
version of gateway/portal to the RADIUS back-end
- Getting rid of pcap and go more native (at the possible risk of  
being less OS compatible) and maybe reading a local DHCP lease file  
on start-up and doing macauth on each

If anyone is interested in testing and/or merging more changes, let  
me know.

Cheers,
David

On May 10, 2007, at 1:51 PM, wlan at mac.com wrote:

> Hello,
>
> I have been making some changes to improve the WISPr and RADIUS  
> implementations in WifiDog. The changes, thus far, amount to the  
> following highlights:
>
> In the gateway:
> - The gw_mac (gw mac address - linux only) and mac (client mac  
> address) parameters are sent to the login page
> - Added WISPr Proxy XML to the initial redirect content (with  
> NextURL being that of the login/ page, plus some extra attributes)
> - Added ability to do a gateway:port/wifidog/auth? 
> token=...&logout=1 request on the gateway to kick-off a logout locally
> - Added argument to auth_server_request() for a 'reason' field used  
> during logout
> - Removed the HTML pages printed to HTTP redirects (never gets seen  
> anyway, not only have WISPr XML added)
>
> In the portal:
> - In WISPr mode (login/index.php?wispr=1&...) the login script will  
> do a login after selecting the network from the username  
> (supporting prefix and postfix RADIUS realms standards)
> - WISPr XML added for several stages in login/index.php (login,  
> token redirect, logout, etc)
> - Logout() / acctStop() get sent incoming/outgoing stats, as well  
> as reason
> - Support for RADIUS Calling/Called-Station-Id attributes in access  
> and accounting requests
> - Support for RADIUS Acct-In/Output-Gigawords attributes for  
> rollover of the Acct-In/Output-Octets (where acct-in/output-packets  
> is mistakenly being used -- wifidog does not know in/out packet  
> counts)
> - Based on the reason, more appropriately setting Acct-Terminate- 
> Cause (user-request, idle-timeout, etc)
> - Major changes to AuthenticatorRadius to better control attributes  
> (added file classes/RADIUS.php to overload Auth/RADIUS.php functions)
>
> In the database:
> - Added fields for node_mac and session_id to connections table
>
> The database changes are needed to store some data for the RADIUS  
> session. The reason for session_id is because I wanted to include  
> Acct-Session-Id in the RADIUS Access-Request (a common thing to  
> do). So, this 'token' is generated before the actual authentication  
> token and is instead used for Acct-Session-Id. Node mac address is  
> used for Called-Station-Id where the existing user_mac is used for  
> Calling-Station-Id. I do put the user_mac into the database during  
> record insert now though... (still gets updated later too)
>
> For WISPr testing, I have been using this handy tool: http:// 
> ap.coova.org/wifi/
> You go to the url from behind the hotspot - where coova.org must be  
> in your walled garden. It is a self-signed applet because it needs  
> to access URLs that are not in your walled garden - just like a  
> smart-client - to pick up the WISPr XML. Source is found here:  
> http://dev.coova.org/svn/cjradius/java/applet/
>
> To do:
> - Take attributes from AccessAccept (session-timeout, bandwidth  
> limits, etc) and configure wifidog appropriately.
>
> When done, you will be able to use and roam with Coova AAA! ;)
>
> Benoit, thanks for your help on IRC -- I'll see you there.
>
> Cheers,
>
> David
> coova.org
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog