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

[Jason Potter]

Hi All,

After reading all the discussion, would like to try and summaries the
authentication and device options we have and what we have to make decisions
about.  Please add to this if I have missed something or modify it if I have
incorrectly summariesed.

Basically there is a range of devices that we want to be able to connect to
our hotspots which can be broken down into two basic groups:
	1) Devices with browsers
	2) Devices without browsers

With Group 1 the authentication approach could be one of the following:
	a) User accesses port 80 and it brings up login page and the user
logs into hotspot
	b) Users device is automatically authenticated based on whitelisted
mac addresses
	c) Users device is tracked by it's mac address but no authentication
takes place (No splash page is presented), the user just has predefined
limits placed on their connection.  Limits would include ports, time,
download amounts and bandwidth. 

With Group 2 the authentication approach could be one of the following:
	a) By the WISPr approach
	b) Users device is tracked by it's mac address but no authentication
takes place (No splash page is presented), the user just has predefined
limits placed on their connection.  Limits would include ports, time,
download amounts and bandwidth.

In the hotspot I want to configure, I want to allow the following
combinations:
	Device 1 and auth method b)
	Device 1 and auth method c)
	Device 2 and auth method b)







-----Original Message-----
From: wifidog-bounces at listes.ilesansfil.org
[mailto:wifidog-bounces at listes.ilesansfil.org] On Behalf Of Benoit Grégoire
Sent: Thursday, 2 February 2006 5:29 AM
To: wifidog at listes.ilesansfil.org
Subject: Re: [isf-wifidog] How to Auth non-browser based devices

On February 1, 2006 11:23 am, Michael Lenczner wrote:
> Benoit - gotta disagree with you here.  I think this is your
> (admittedly acute) legal mind at work.  Consistency is not the highest
> goal.  Comprimise is very important (i know you know that).  And I
> know that you hate to look arbitrary - but it's not the worst
> sin,either.  It's what happens when you make comprimises.

Spoken from the man who talks about putting values in technolgy, I must say
I 
find that surprising.  In any case, I disagree, both personally and 
professionaly.  

Personally, I always act in a manner that is as consistent with the values I

defend if I possibly can.  If I can't, I explain why I can't so people do
not 
think I am a hypocryte.

Professionaly, I've seen first hand the consequences for an organisation of 
acting in a way that is inconsistent with the values/policies it outlined.  
Especially when the reasons stated for the exception are not the ones for 
which it was made, or when no reasons are stated at all.  Either
journalists, 
competing organisations or people who just plain don't like you will 
eventually jump at the chance to make those inconsistencies public.  They 
know people usually put more value on an organisation's action than it's 
stated policies, and I can't blame them.  It's often not fatal to a 
commercial entity that operates to make money, but it can easely kill an 
organisation relying of volunteers to push an agenda.

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.

> "means the group deems all other services less worthy of
> convenience/consideration."
>
> That's not true.  If we whitelist a VOIP port, it's not because it is
> "more important" than Web.  It's just that, for the time being, that
> could be the best way to deal with it.  it all depends on the
> situation (type of user, what kind of service someone's trying to
> offer, etc).

If we whitelist a VOIP port to any destination, it means that we consider
that 
showing some sort of credential for using network resources is no longuer 
mandatory in all circumstances.  That's a fact, so the question becomes what

are the circumstances wothy of an exception.

So why is VOIP on embeeded devices (likely used by less than 1% of our 
userbase), worthy of this consideration, while email over pop or imap
(likely 
used by a good 20% of our userbase) isn't?

The only real reason I can see is that many wifi phones cannot open a web 
browser at all.  Obviously that's not our fault.  If it is reason enough to 
warrant opening the ports, why shouldn't it be allowed for every devices in 
that same situation (Nintendo DS, WiFi wecams, WiFi cameras (for uploading 
your pictures), etc)?

If so, what happens once a device needs to use port 80, we go back to all
open 
hotspots?  Off course it will work technically, but it will destroy ISF in 
the process.

This is not just being devil's advocate, MDCNs sensors communicate over http

but do not have a browser (or an UI of any kind for that matter).  Lucky for

us they communicate with a single server.  I boatload of devices communicate

over http using web services, and there will be more in the future.

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.
-- 
Benoit Grégoire
Technologies Coeus inc.

-- 
Benoit Grégoire, http://benoitg.coeus.ca/
_______________________________________________
WiFiDog mailing list
WiFiDog at listes.ilesansfil.org
http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog