[isf-wifidog] How to Auth non-browser based devices

[Gabe Sawhney]

I had a conversation about this recently with Steve Wilton from
Wireless Nomad.  He pointed out WISPr
(http://www.wi-fialliance.org/opensection/wispr.asp) which I'd never
heard of, and suggested that if VoIP phones (and other devices with no
browser) were made compliant with this standard, it'd solve the
problem.  The phone doesn't need a browser, it just needs to send an
HTTP request with its owner's username and password.  WISPr
(apparently -- I haven't read the document) recommends a standard (ie
the name of the username and password form fields, etc.) for this.

Now, I can't find documentation of any devices adopting the WISPr
recommendation (and I *can* find lots of skepticism about WISPr), but
to me, this seems like the ideal answer to this problem.

It doesn't look like this is going to happen anytime soon (if at all),
so clearly something else is needed in the meantime.

Gabe


On 2/1/06, Michael Lenczner <mlenczner at gmail.com> wrote:
> i'll respond to some of these
>
> On 2/1/06, Dana Spiegel <dana at nycwireless.net> wrote:
> > Some comments:
> >
> > 1) this is likely to be an involved and confusing process for most normal
> > people, since they'll look at you and say "I want to get phone access, and I
> > don't own a Mac". Asking for people to enter in their MAC address is like
> > asking them to enter the serial number for the engine block in their car.
> >
> amen!  it's nice to have someone fighting for stupid users.  Even our
> regular sign-up process is very difficult for many people.
>
> > 2) Great idea, though if we could enter the server whitelist via DNS names,
> > and have the wifidog auth update the IP automatically, that would be even
> > better
> >
> > 3) Even better idea. If someone is going to be smart enough to tunnel
> > traffic like this, then its likely that they're smart enough to spoof a mac
> > address or do something else to get around any security. Plus I don't think
> > there's a significant risk for this, and our goal should be to make the
> > hotspot as easy to use as possible. This is the only way that people can
> > just pull out their VOIP phone and use it without a problem.
> >
> true!  we don't need to worry about the 0.001% of people that will
> tunnel traffic.  give them up.
>
> > 4) I don't think this will work for VOIP phones, who can't even click
> > through the splash page. Unless I'm missing something.
> >
> I think he was saying leave all ports open - but the first time
> someone uses port 80 to redirect them to a splash screen.  This solves
> the question of showing local content and displaying a disclaimer or
> AUP.
>
> > 5) This is also a good idea, though we'll constantly be playing catch up
> > with the network device providers, and this will be lots of overhead work
> > for the network operators. If we go this route, WifiDog should publish a
> > list of MAC addresses and their device category, and allow network operators
> > to click a button that says "Allow all VOIP phones to use this network
> > without authenticating", which will cause the auth server to suck down a
> > constantly updated list of MAC address ranges for VOIP phones. Same is true
> > for PSP and DS, and possibly other device classes as well.
> >
> >
> > Dana Spiegel
> > Executive Director
> > NYCwireless
> > dana at NYCwireless.net
> > www.NYCwireless.net
> > +1 917 402 0422
> > Read the Wireless Community blog:
> > http://www.wirelesscommunity.info
> >
> >
> > On Feb 1, 2006, at 12:05 AM, Benoit Grégoire wrote:
> >
> > On January 31, 2006 11:37 pm, Jason Potter wrote:
> > Hi All,
> >
> > Just an extension to the discussion below, what are the approaches to
> > giving free wifi to devices in a venue that don't have a browser.
> >
> > 1-Tie MAC adress(es) to a single user account who vouches for it
> > (http://dev.wifidog.org/ticket/19).  Only slightly more
> > insecure than normal
> > captive portal operation.
> > 2-Whitelist specific servers ("perfectly" secure, allows the group to ask
> > money from their operators for the priviledge since they run a business on
> > your network).  Good for the DS and VOIP operators, doesn't work for
> > allowing
> > you to connect to you own asterisk server for example.
> > 3-Whitelist specific ports (such as SIP).  Once you do that, anyone can
> > tunnel
> > any kind of traffic trough them.
> > 4-Don't run any authentication at all.  Works fine for those who only run a
> > portal to display a splash page and terms of service.
> >
> > I hadn't tought of Pete's solution:
> > 5-Whitelist a range of MAC adresses by manufacturer.  Only works when the
> > manufacturer and the service to be whitelisted are the same, so it would
> > work
> > for the DS, but not for a wifi phone).  Also, once the users know whose
> > device is whitelisted, they no longuer have to guess of find a MAC adress to
> > spoof.
> >
> > If anyone has other ideas, please speak up.  So far there is no perfect
> > solution.
> >
> > --
> > Benoit Grégoire, http://benoitg.coeus.ca/
> > _______________________________________________
> > WiFiDog mailing list
> > WiFiDog at listes.ilesansfil.org
> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >
> > _______________________________________________
> > WiFiDog mailing list
> > WiFiDog at listes.ilesansfil.org
> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> >
> >
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>