Archive for May, 2007

david @ 2007-28-05 10:55 AM
Filed under: Uncategorized
WiFi Everywhere…

Many people think that WiFi will be everywhere sometime soon. I agree, but wonder in what form, or rather, how many forms. Muni wireless projects are happening all over the place, as they should. There are substantial benefits for public infrastructure - providing private networks for city departments and emergency services. But, what about public access? Given that politics is involved, I somehow don’t think ‘anonymous’ open access to WiFi will last long, not on that scale. Just one high-profile law suit of a minor or transient downloading illegal porn or committing other crimes over the Internet and there’s the end of that. And what about CALEA? Can a wire-tap be targeted and guaranteed without being certain of IP or even MAC address? Then there is also the constant threat of the so-called Evil Twin and the harvesting of MAC addresses, usernames and passwords.

The need for 802.1X

Wireless security. It just sounds right. And it is right. Particularly in certain circumstances. It’s when you’re talking massive coverage through a city-wide mesh or in the homes of residents. Many people already use some kind of wireless security in their homes, usually WEP (not good) or WPA Personal (better). Others intentionally leave their access points open as a way of sharing or just don’t know any better. Regardless, I believe people want security and the ability to share with friends and community. This is possible by passing around WEP or WPA-PSK keys, made easy with the help of software. But, perhaps not well suited for the muni or large scale community.

For ubiquitous WiFi access networks, the solution lies in WPA-Enterprise and 802.1X. Wireless security using standard technologies; takes advantage of inter-community roaming and provisioning features found in access controllers using RADIUS; and very likely to be compatible with WiMAX networks down the road.

What makes 802.1X so great? The answer can get technical, but boils down to 1) robust wireless security, 2) centralized access provisioning and configuration, and 3) being able to ‘authenticate’ the network before revealing any username or password (similar to how SSL works on secure websites). Then, why don’t people use 802.1X more? First of all, people do! At work, on campus, even at commercial and public hotspots. Perhaps main-stream adoption is slow because Windows doesn’t make it overly easy to configure - certainly not as easy as on a Mac. But, that might soon change as cross-platform “smart clients” become more widely available and easy to use.

The need for captive portal

Ok, wireless security is great, but there is a purpose to having a captive portal - almost always with an “open” access point (no wireless security), though not necessarily. The portal is important to communities and venues like cafes, hotels, airports, and so on, not only to sell access, but to give useful location specific content. In many of these cases, the threats of the open access point are mitigated by the fact they are in public places - people doing something they shouldn’t be tend to be suspicious in other ways and draw attention (as the theory goes). Additionally, some commercial WiFi products can help venue owners detect and deal with rogue access points and other security threats. Captive portals applications can be made relatively safe for casual use. And, do visitors of such places really expect their traffic to be secure? I would guess the expectation of security is less than when connecting at home, work, school, or the city mesh - places where people feel comfortable and networks they use every day.

That’s not to say having a captive portal, or “walled garden,” isn’t beneficial even when using 802.1X. It can provide instructions on how to access the Internet using an existing account (of this or a roaming network, or voucher code) and how to obtain one if new to the network. Also to give general information about the community, the project, maps of the area, and where to find help.

Community awareness

Large scale WiFi networks should, of course, service their communities in a responsible way. I believe doing so is part technical: wireless security, part social: not promoting “all WiFi is good”, part legal: not a safe haven to do all the things you don’t want to do from home, and part business: don’t ruin the commercial and community WISP.

What is still needed is the ability to seamlessly access your home and community WiFi without having to compromise individual security. At the same time, being able to selectively share and use the access of others. Using your own credentials for 802.1X, in friends’ homes or in the city mesh, or captive portal in the community centers, cafes, hotels,… places you “trust.” As previously noted, we still need client software to balance security with ease-of-use, and that is coming. But, we also need for communities to be built and a public roaming network to be established. One step at a time.

Well, there’s one opinion. What’s your’s? Leave comments or join us in the forum… we are particularly interested in hearing from those responsible for networks with an interest in community roaming.

david @ 2007-3-05 7:57 AM
Filed under: Development
Embedded Web 2.0

In a previous post, the idea of using the Google Web Toolkit to create a new kind of embedded web administration interface for devices was discussed. I continue the discussion by providing some examples and a working demonstration of the user interface.

The interface is designed, in this case, to be the administrative web console of a OpenWrt-based firmware. As such, it is a tool to configure (linux) system parameters and files - which may be different depending on the underlying system. For instance, the WhiteRussian branch of OpenWrt use NVRAM settings while Kamikaze uses the new UCI Configuration.

Working with XML

The application in this example uses XML to define the system configuration and also to define the user interface to edit this configuration. XML is well suited for this purpose and offers many benefits, including:

  • Easy to read and edit by hand
  • System independence and interoperability
  • Transformed into other formats using a structured language
  • Excellent open-source libraries, tools, and resources

The well-formed structure of the XML resources are converted into JSON objects by a CGI program running the server-side of the application. The GWT interface exchanges JSON objects with this CGI back-end to load or save data.

Defining system configuration

The GWT-based user interface is designed as a configuration editor. The configuration itself is stored in XML as specified in the sysconfig DTD. The DTD defines how a system is configured and is used for basic syntax verification. Here is a portion of the “config.xml” system configuration based on this specification:

<sysconfig>
  <system>
    <settings boot_wait="true" hostname="Coova"/>
  </system>
  <network>
    <interface id="loopback" proto="static" .../>
    <interface id="lan" proto="static" .../>
    <interface id="wan" proto="dhcp" .../>
  </network>
  ...
</sysconfig>

The XML is transformed into JSON by the CGI program when sent to and stored by the GWT application (as a JSONObject), as shown in the “Status / Config Tree” tab of the demo.

Defining the user interface

The user interface screens are defined in XML based on the cap-ui DTD. The portion that builds the systems settings screen to configure the above XML segment is as follows:

<cap-ui>

  <menu name="System">

    <submenu name="Settings">

      <inputset name="System Settings" object="system.settings">

        <input label="Host Name" key="hostname">
        </input>

        <input label="boot_wait" key="boot_wait">
          <option name="Enabled" value="true"/>
          <option name="Disabled" value="false"/>
        </input>
        ...
      </inputset>
      ...
    </submenu>
    ...
  </menu>
  ...
</cap-ui>

Configuration transformations

Taking the XML configuration and using it to set the underlying system configuration is done using XSLT. Transforms take the XML and produce scripts for WhiteRussian (example) and Kamikaze (example), the output of which is shown in the “Status / Config Files” tab of the demo.

The demo

See an on-line demonstration of the user interface using something similar to the above configuration. Please, keep in mind it is still a work in progress and not all the screens and dependencies are defined. The configurations transforms are also incomplete - as is the UCI configuration of Kamikaze.

If you want to help out, come join the forum! (when your done helping out OpenWrt) ;)

david @ 2007-2-05 12:01 PM
Filed under: Releases
Coova AAA Services

If you have been in the forum, you probably already know. But, Coova has launched a new RADIUS AAA service to complement Coova-Chilli and CoovaAP firmware.

About the service

CoovaAAA provides a flexible RADIUS authentication, authorization, and accounting engine designed to make hotspot management easy for users, while also giving them complete control. Users are able to create an account, which provides them with an individual “shared secret” to use when configuring an access point supporting RADIUS authentication — using captive portal or WPA Enterprise (802.1X).

Once signed up and have an access point configured for CoovaAAA, log into the captive portal or WPA network with your Coova.org account. From then on, you will see the AP associated with your account in the portal. You can then share your network with the entire Coova.org community or select individual members. Find members by username or e-mail address, or send an invitation if not already registered.

About the technology

CoovaAAA is built on a highly flexible framework using JRadius along with FreeRADIUS. The main portal is a Java application using Hibernate, Spring, Acegi, XSLT, and many other technologies. The “Manage” section of the portal is an integrated GWT application.

much, much more to come…

Search >>