Network access for guests

Here's a scenario that I've come to call "the coffee-shop problem" because it pertains to a local coffee shop, though it also applies to a home office that might receive visitors. You have a single DSL or cable connection. The challenge: offer Wi-Fi to visitors without exposing your connected computer (or LAN).

I haven't yet found a low-end (sub-$100) appliance that can do this. If you're willing to spend closer to $1000, the solution I'm testing here in my home office at the moment, Fortinet's FortiWiFi-60, solves the problem handily. You can establish firewall, anti-virus, intrusion-detection, content-filtering, and traffic-shaping policies between any pair of its WAN, LAN, DMZ, and 802.11b/802.11g interfaces. That's overkill for the coffee shop scenario, of course. And while it's entertaining for me to fiddle around with the various policies, that's very much an administrative thing, not something a non-technical user would want to do. For the coffee shop and home office scenario, I think there might be a market for a cheap appliance that would isolate a WLAN from its host LAN in a turnkey way.

For the enterprise, of course, this is a more complicated problem. In some cases, you want to isolate visitors from the local network. In other cases, you'd like to be able to collaborate with visitors and share intranet resources with them. Solutions to this problem tend to require administrative support. But that often won't correspond to the way we delegate trust in the physical world. For example, on a recent visit to a corporate campus, I signed in at the visitor center. But when the meeting moved to another building, it wasn't my visitor credentials that gave me access to that building. Rather, I piggybacked on the authorization of the employee who unlocked the door with his card. But since there was no analogous way to delegate network access (isolated or not), I spent the day out of contact with the world.

At the PKI Unlocked summit at Dartmouth College, I saw an interesting approach to solving this problem. Greenpass, one of the projects being directed by Sean Smith, is a prototype system that enables a trusted insider to delegate certificate-based access to a guest. It was set up and running in the seminar room, and it works like this:

  1. On connecting to the access point, the guest is bounced to a registration page.

  2. The guest uploads his or her digital certificate to Greenpass.

  3. Greenpass produces an image based on the guest's public key, and displays it on the guest's laptop.

  4. The guest shows the image to the delegator.

  5. The delegator compares it to an image based on the key associated with the access request, and if the images match, accepts the request.

  6. A SPKI/SDSI certificate is issued for the guest. (Pronounced "spooky/sudsy", these technologies support a decentralized, peer-to-peer approach. The design of Groove was influenced by SPKI/SDSI.)

  7. A modfied RADIUS server accepts the SPKI/SDSI certificate.

There's plenty of rocket science under the covers, but the parts that people do -- compare images, vouch for guests -- are easy and natural. Nice!

Update: Here are some suggested solutions to the coffee-shop problem;

From Seairth Jacobs: D-Link's DSA-3100 Public/Private Hot Spot Gateway. Seairth writes: "I admit it's not sub-$100 and it doesn't provide some of the features as the Fortinet product, but it may be a good compromise. Also, because it doesn't have the wireless built in, it is possible to keep up with the latest and greatest (wireless features) without having to replace the entire device."

From Dave Megginson, Will Glass-Husain, and Eddy Carroll: A 3-box solution, two Linksys (or equivalent) routers connected in a Y configuration with a third that talks to the cable/DSL box. "I have a vague feeling there might be gremlins in this double network address translation," writes Will, "but can't think of a concrete reason it wouldn't work." (Brian Jepson also suggested this to me, a while ago.)


Former URL: http://weblog.infoworld.com/udell/2004/07/15.html#a1040