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

[Dana Spiegel]

On Feb 1, 2006, at 12:53 PM, Benoit Grégoire wrote:

> Making exceptions do not have to be inconsistent with policies.   
> When the
> reasons for the compromise and it's consequence are made explicit  
> upfront, or
> even better when it is explained how the exception helps the  
> ultimate goals
> of the policy, all is good.  If not, it means that said policy wasn't
> important to the organisation after all, or improperly justified  
> and can be
> ignored.
>
> When the nature and cost of a single compromise isn't explained,  
> the ripple
> effects can often make you miss the goals of the original policy  
> completely.
> Even if it doesn't, dealing with the problem upfront is most of the  
> time far
> less time consuming than doing it when it blows up in your face.
>
...
> Making an exception "just because it's convenient for 0.3% of our  
> users" and
> not considering the long term consequence on our policies and  
> hoping that
> people won't exploit it is not pragmatism, it's magical tought.
>
> I'm not saying ISF shouldn't do it, I'm saying that we should think  
> long and
> hard if we want to do it that way, and most importantly WHY.


Good points, all.

I think it would help to spell out what the problem is, just so that  
we're clear:

* We have some class of devices that don't have any way to authenticate.
* Though these devices are in the vast minority today, it is likely  
that in the near future, they will have widespread use (lots of VOIP  
phones are coming to market now, and Nokia is getting ready to  
release theirs as well).
* We generally have a community that: (a) can find it hard to figure  
out the technologies -- they understand how to use usernames and  
passwords, but not about the specifics of networking hardware (see 1  
below), and (b) are likely not going to have a computer with them to  
even sign up their phone when they need to use it.
* We have hotspot owners who only know how to powercycle their  
equipment, and even then do it wrong
* We have Community Wireless groups that maintain the network and  
hotspots for whom we should be reducing workload, not increasing it.

So, given that we have a policy of tracking usage and maintaining  
security, we need to see if there's a way to maintain this policy  
while addressing the above. If not, we should evaluate under what  
circumstances we will be willing to bend this policy, and by how much.

I suspect that we don't care so much about authenticating a user as  
we do about being able to determine usage of the service by a  
particular piece of hardware (this may be a bad assumption for some  
groups, but bear with me). So, we need to track usage, even if we  
don't authenticate. We will also likely want to give some form of  
traffic QOS to the devices that need it, which means that we need to  
perhaps understand a class of device by its MAC address.

So if we allow traffic without authentication over VOIP ports, but  
keep track of usage by MAC address, and also indicate the class of  
device in the reporting page, does this work for everyone for v1? In  
v2, we can add tying a second/third/fourth MAC address to a user  
account when authenticating, and also enable QOS for know protocols/ 
devices, and enable time limits for classes of device. This will  
allow us to say that a VOIP handset gets through w/o authentication  
always, but a computer doing VOIP must authenticate first, since  
there's a browser handy.


(1) I have people all the time ask me about why they can't get  
NYCwireless service in their apartment. Never mind that we have a map  
that clearly shows that there's no hotspots in their neighborhood. Or  
other people that contact NYCwireless about our wireless service at  
an airport or in a starbucks, only to find out that they should be  
contacting t-mobile or some other company. Don't underestimate the  
lack of understanding about wireless technologies in our userbase.  
Any understanding that most people give the impression of having is  
only a very thin veil over their lack of knowledge thereof.

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