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

Max Horváth max.horvath at maxspot.de
Jeu 2 Fév 05:37:56 EST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, I've been talking about WISPr some weeks ago.

But WISPr won't help us with this situation. WISPr isn't even any  
standard or protocol.

It's a recommendation for how to do roaming.

So it really won't help us in this this situation - it could help us  
with the goal of roaming users of different WiFi groups.

But to come back to non-browser-based devices.

What about this:

We could have a central database of MAC addresses which we know  
belong to devices like VOIP phones that don't have a browser. This  
database could be classified to what those devices do. I.e. it's a  
VOIP phone using port 5060 and 5061 for running SIP.

In this case we could have a user like NO_LOGIN_SPLASH for this phone.

So everything this phone does could be monitored (for stats) and QOS  
could be done.

But the device would also only be allowed to user those two ports.

For a laptop trying to access those two ports we could deny access to  
the ports, because we don't have the MAC address of this laptop in  
our database of devices know to have no browser. The user of the  
laptop would have to authenticate before being able to do VOIP using  
any VOIP client.

Hope this text is kinda understandable ... ;)

Cheers, Max!

Am 01.02.2006 um 17:25 schrieb 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
>>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFD4eEG+BKgC+eQ3ooRAsqWAJ9IgHtCOiqhn1DYyBHsw3EFEqkEdgCfYP9K
ntxI/WybQoHDhEovBzkTnlw=
=6AJ9
-----END PGP SIGNATURE-----


More information about the WiFiDog mailing list