Changes between Version 2 and Version 3 of doc/developer/WiFiDogRadiusWISPr

Show
Ignore:
Timestamp:
11/14/06 13:12:32 (15 years ago)
Author:
rnissley@…
Comment:

minor grammatical/clarity edits

Legend:

Unmodified
Added
Removed
Modified
  • doc/developer/WiFiDogRadiusWISPr

    v2 v3  
    22Original author: Benoit Grégoire, last modified: [[Timestamp]] 
    33= What is RADIUS and current support in wifidog = 
    4 [http://en.wikipedia.org/wiki/RADIUS 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.  User's were meant to self-subscribe, to be computer validated and for a computere to enforce abuse-control policies.  Most organisations that the core developer's belong to still don't have a need for it. 
     4[http://en.wikipedia.org/wiki/RADIUS 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. 
    55 
    66However several new users of wifidog not only want to human-verify users, but also have existing userbases in RADIUS. 
     
    2727 
    2828== Allowing the wifidog gateway to directly talk to a standard RADIUS authentication server == 
    29 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 it's success and reuse) is that it's the captive portal equivalent of a dumb terminal.  It was explicitely designed to get rid of all the crypto dependencies (have the server insure security) and move the login and portal UI to the server. 
     29We 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. 
    3030 
    3131If you want to only display a disclaimer page with no central server, you should either 
    32  * Use NoCatSplash (an possibly other captive portals) which is designed for this. 
     32 * Use NoCatSplash (or possibly other captive portals) designed for this. 
    3333 * 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. 
    3434 
    3535== Using RADIUS as the gateway-auth-server protocol == 
    36 It would actually 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: 
     36It 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: 
    3737 * 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. 
    38  * It may lead people to think (or repeatedly demand) for the wifidog gateway to be usable against a standard RADIUS server, which would be a tech support nightmare. 
    39 It may, or may not happend when we work on version 2.0 of the wifidog gateway, which will have a new protocol  
     38 * 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. 
     39It _may_ happen when we work on version 2.0 of the Wifidog gateway, which will have a new protocol  
    4040 
    41 == Using RADIUS to allow wifidog auth server to communicate among each other == 
    42 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 option: 
     41== Using RADIUS to allow Wifidog auth server to communicate among each other == 
     42Many 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: 
    4343 * Code support for the RADIUS protocol completely in PHP all the way up from the low level PHP socket functions http://php.net/sockets 
    44  * Code support as a C PHP package, which would in practice meand people would have to compile their own PHP to user it, which doesn't seem likely. 
     44 * 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. 
    4545Neither of these solves the quirky problem of running PHP code as long-term listeners. 
    4646 
     
    5656 
    5757== RADIUS attribute support (chapter 5) == 
    58 Which RADIUS attributes to use to in the WISP sharing scenario.  While most's user's 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. 
     58Which 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. 
    5959 
    6060== Re-Authenticating using PANA (Appendix B) == 
    61 This approach (which is basically what NoCat did) has been rejected in the WiFiDog design phase, for three reasons: 
     61This approach (which is basically what NoCat did) has been rejected in the WifiDog design phase, for three reasons: 
    6262 * It's a nightmare for the user (must keep java or javascript open all the time, and your device must support it) 
    6363 * Security wise, five minute is still plenty of time to do something malicious and "frame" another user. 
    6464 * 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). 
    65  * For community groups (the primary constituency), artificially inflating a user's usage of the network to malicioussly run up his bill is not an issue (12h at 0$/hour is still 0...) 
     65 * 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...) 
    6666 
    6767== The smart Client to Access Gateway Interface Protocol (Appendix D) == 
     
    6969 
    7070= What about supporting WPA? = 
    71 There has been some recently renewed interest in supporting WPA with wifidog.  Let's first answer the most basic question, is it worth doing in (or more exactly with) wifidog? 
     71There 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? 
    7272 
    73 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: 
     73Yes, 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: 
    7474 
    75  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.   
     75 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.   
    7676  * Advantages 
    7777   * Requires no modification of the gateway 
     
    8080   * Requires a separate, completely redundant RADIUS server 
    8181   * Requires the client to have a web browser to trigger the standard wifidog auth exchange with the server. 
    82  1. 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. 
     82 1. 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. 
    8383  * Advantages 
    84    * Does not requires a separate RADIUS server 
     84   * Does not require a separate RADIUS server 
    8585   * Would work with WPA client with no web browser 
    8686  * Drawbacks 
    8787   * Requires writing part of the radius transport protocol on the gateway side (re-inventing the wheel) 
    88 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. 
     88This 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. 
    8989 
    9090