[OpenWireless Tech] Hello World
Todd Freeman
todd at chiwifi.net
Fri Nov 2 06:39:29 PDT 2012
I think what you want is openwisp http://openwisp.org/architectures.html
So all the work is already done, you just need to translate it into
English :-)
On 11/02/2012 07:31 AM, Natanael wrote:
>
> Well, that's why we are going to create a new protocol, isn't it? :)
>
> We can create custom federated radius servers or something like it,
> whatever we need for the WiFi Direct router to be able to know what it
> has to know for giving the client access to another router's WLAN.
>
> We should never have to put all the traffic on a single box. Ideally
> the traffic goes client -> router -> VPN, no more steps needed. If the
> VPN is that client's user's home router, that's great.
>
> If we want to remove liability from router owners to create an
> incentive, we are probably going to need VPN:s. And in this case it
> simply does not matter who runs it. By the way, physical proximity
> would actually make this better than a VPN from a major company for
> most people (less load on the internet routers).
>
> Den 2 nov 2012 11:03 skrev "Todd Freeman" <todd at chiwifi.net
> <mailto:todd at chiwifi.net>>:
>
> I am not sure if that's quite how it would work, the reason
> radius is used for auth, is because it handles both auth and IP
> assignment, which is how it can set things like QOS on connections
> based on credentials.
>
> So I do not think you could have multiple routers with different
> ISPs using the same radius server sometimes but not other times,
> what you would actually have to do, is add a bridge between the
> WiDi and their home router and then tunnel all the traffic to the
> radius server. This is fine for transient internet usage, but as I
> stated, I would hope for it to be used more widely and more often
> then that, which would require more capacity to be donated by each
> router, many ISPs are already placing 500gb caps on their users
> (comcast). so if large number of people used this, it would just
> strain the hosts which will eventually abandon it because of
> getting throttled when it becomes popular.
>
> Minimal costs need to be incurred by the router owners if we want
> the system to be even reasonably large.
> But in this model 100% of the costs and also shaky legal liability
> (if they are not using vpn) are on the router owners.
>
> VPNs do remove liability from router owners, but tunnelling from
> one persons home connection to your home connection to the
> internet, triples the traffic required to do anything on the
> internet, this is not sustainable on an even moderate scale.
>
> On 11/02/2012 04:50 AM, Natanael wrote:
>>
>> I want to add that not all routers will need WiFi Direct in my
>> scheme.
>>
>> If multiple routers nearby use the same Radius server or they are
>> federated, one WiFi Direct router could deal with setting up
>> access for them all. The routers will simply just run something
>> like OpenWRT, and when clients connect the router ask it's radius
>> auth server if the credentials are OK. This means you only need
>> one WiFi Direct router visible in each area, the rest can be
>> ordinary routers.
>>
>> This means you don't need to hack in WiFi Direct support in all
>> your old devices OR replace them all. Just get a single new one
>> (if you just cover a small area)! (Or hack in WiFi Direct support
>> if you have one that has drivers for that available)
>>
>> Den 2 nov 2012 09:34 skrev "Natanael" <natanael.l at gmail.com
>> <mailto:natanael.l at gmail.com>>:
>>
>> Your suggestion actually overlaps with mine.
>>
>> Those "identity providers" I mentioned could be any kind of
>> local organizations, and you'd have an account with them. The
>> routers don't deal with the VPN link as such other than at
>> the setup phase, it is your own computer that runs the actual
>> VPN client. The router just relay your traffic to that VPN.
>> For those with no accounts, these organizations could
>> possibly offer free access anyway. Maybe data-capped,
>> bandwidth limited or time limited. Or even unlimited free
>> access, if there's enough support for that. It all depends on
>> local policies.
>>
>> Then we still have a different issue with unconfigured
>> clients meeting unconfigured routers, as none will have a VPN
>> configured. Should the user be warned? Should we ignore it as
>> this still beats unencrypted open networks? Or should we
>> suggest using Tor?
>>
>> We'd also still require WiFi Direct support as I don't see
>> how we could achieve a simple standards compliant solution
>> another way (how will the client connect and know the
>> connection is secure?). We'd end up with either an open and a
>> closed network in parallell (connect to one for keys to the
>> other) or a set of standard credentials for the initial
>> connection.
>>
>> The big advantage with WiFi Direct is the ability to connect
>> to all local AP:s at once to negotiate about a connection.
>> This makes it MUCH faster than a series of WPA2 network
>> connections + access negotiations in a row.
>>
>> Den 2 nov 2012 09:06 skrev "Todd Freeman" <todd at chiwifi.net
>> <mailto:todd at chiwifi.net>>:
>>
>> So I looked through the archives and I see some repeating
>> patterns.
>> 1st people really want to jump on the VPN bandwagon and
>> assume all users can use it, but noone ever mentions
>> where the other end of the VPN is supposed to connect to.
>> "the internet" is a copout answer. Its the subtle way of
>> saying "well people are going to have to pay for
>> something or figure something out on their own"
>> This is kinda what separates free from non-free, you
>> can't offer a service for "free" with "oh by the way you
>> have to pay for this addon or it doesn't work" That's
>> not free, it's just marketing BS.
>> It was suggested that the person running the AP would
>> also run the VPN, there are so many problems with this
>> its not funny.
>> It is essentially putting all your security hope on a
>> completely random AP. It's odd that people would suggest
>> that while also pointing out that the system must be
>> designed to allow for malicious APs.
>>
>> This of course all ignores the processing overhead of so
>> many layers of encryption, if people are connecting to
>> some linksys home router, it is not going to have the CPU
>> to handle many VPN tunnels.
>>
>> I think an important point we need to ask ourselves here
>> is, what do you want the fundamental coverage to be like,
>> and how do you expect the clients to use the network.
>> Please do not take offence to this, but from what I can
>> tell the roadmap is designed to be very similar to tor,
>> something you use every once in a while to do a limited
>> number of things because its ungodly slow, but with the
>> added bonus of very spotty coverage and no idea where any
>> of the APs are, so you would be biking/ walking around
>> (not driving because you would leave wifi range before
>> you even detected it). Also the quality is impossible to
>> maintain even to a minor degree as you will likely have a
>> lot of people with DSL modems and 128-512k upload caps.
>>
>> What I like to envision is something similar to clear4g,
>> A network with ubiquitous coverage that is always on, and
>> the security is managed by any local org
>> (towns/cities/educational institutions etc..) not by the
>> people running the APs. By making sign up for the central
>> cert auth anonymous and easy, the network operator can
>> still comply with DMCA requests, etc.. by terminating the
>> account (but leave email acct intact for 30days for them
>> to remove anything they need) Thus the network operator
>> still gets safe harbour protections without permanently
>> blocking anyone’s access, and without having any useful
>> information to give to LE by design.
>>
>> But one of the things the above system has that is
>> crucial for its adoption, is capacity. So long as we use
>> industry standards for the auth mechanism (wpa2-ent)
>> which almost all routers already support, the home users
>> only have to change the router mode from router to AP
>> with wpa2-ent,and point it at the local network operators
>> servers. no special firmware required. Anyone can make a
>> system more complex, layering on encryption with a shovel
>> is not the answer.
>>
>> By allowing the network operator things like centralized
>> auth, they can also be encouraged to run addon services
>> like increased bandwidth caps as well as location based
>> services or even telco services. This is how we will be
>> able to break the monopoly comcast,verizon,att, et al ..
>> have on internet. We need to be able to make a business
>> case to people we want to run this system.
>>
>> So as I said, what do you want the client experience to
>> be like ? If you want it to be like tor, noone will want
>> to use it for their everyday use. Besides if we already
>> have tor, what is the point of making another tor ?
>>
>> Yes the system I am proposing does requires a bit of work
>> in getting the systems to all talk to eachother, but I
>> think that is still much more simple then inventing
>> entirely new authentication systems. Also we should never
>> design a system that allows either the router operator or
>> the end user to be insecure by doing nothing, and
>> requires "addons" to be secured. We all know how that
>> goes 70% of the time.
>>
>> TLDR; network needs to be designed with very low
>> overhead, not rely on VPNs to be secure, and have
>> throughput that is better then tor. and finally it has to
>> be easy to incentiveize large orgs to adopt it.
>>
>>
>> On 11/01/2012 06:15 PM, Natanael wrote:
>>> This mail will (subtly) reference the roadmap mail that
>>> just was sent to this list.
>>>
>>> So here's my new suggested solution:
>>>
>>> Routers announce themselves over WiFi Direct as well as
>>> using a regular SSID. The "WiFi Direct announcements"
>>> also points to that SSID.
>>>
>>> The network is protected with WPA2 enterprise, using
>>> certs or dynamically created temprorary accounts. An
>>> OpenWireless compatible client will detect the WiFi
>>> Direct announcement (also called WiDi, that's the name
>>> I'll use later here) and see that the router supports
>>> OpenWireless. It will then send a request using WiDi for
>>> specific rules for that network.
>>>
>>> If the rules match what the client have been configure
>>> to automatically accept, it sends a request to connect
>>> over WiDi. The router responds over WiDi with "connect
>>> to my SSID ABC using credentials XYZ". The user don't
>>> have to do anything at all.
>>>
>>> If the rules don't match, it simply asks more networks.
>>> If none match, it presents the networks to the user,
>>> maybe even autosorting them based on how well they match
>>> his rules for autoaccept. So then he could see that
>>> network ABC says that to connect to that network, he
>>> only gets to connect to one IP that he first notifies
>>> the router of (which means "which VPN do you use?", "I
>>> use VPN X"), or that some services are restricted (port
>>> blocking, the user can demand acccess to certain ports),
>>> or that he needs to autenticate using a certain method,
>>> or that it is a paid network, etc...
>>>
>>> Preferably we would support a reasonably wide set of
>>> default rules that can be set, and they should be
>>> expressable using XML or JSON or another computer
>>> understandable format that enables autoagreement if both
>>> parts accept the same rules. A bonus is that this makes
>>> it multilingual directly, a person with no understanding
>>> of english will see the network rules presented in his
>>> native language when he connects to a router in for
>>> example an english country. This makes it great for
>>> tourism (this alone can be a HUGE selling point to
>>> router manufacturers, more tourism deals for them!).
>>>
>>> For authentication, one could imagine that the user
>>> could use OpenID (as previously mentioned), a SIM
>>> (smartcard) connected to a carrier or some other
>>> connection to a central system, and the router could
>>> tell the user what it supports (and maybe which of these
>>> servers/providers trusts). The client could then
>>> authenticate directly to his "identity provider"
>>> tunneled, and the identity provider then notifies the
>>> router when the user has successfully authenticated.
>>> This could enable router owners to link their routers to
>>> a wide list of local phone carriers, and let people on
>>> those networks to automatically connect. The carriers
>>> could possibly even provide VPN:s as a part of this
>>> setup. The router owners would be off the hook legally
>>> and maybe even get rewarded by the carriers (paid for on
>>> the customers' bills) for extending their networks. This
>>> don't have to apply to only phone carriers, it could
>>> apply to ordinary ISP:s and more.
>>> As a matter of fact, the router owner could even let the
>>> router connect to a service that deals with these
>>> contracts with these providers, so the router owner
>>> don't have to get a thousand contracts with various
>>> companies for this. These "authentication middlemen"
>>> could have international deals with each other, and they
>>> still wouldn't know who is using the service thanks to
>>> the tunneling used for auth.
>>>
>>> On all networks with authentication, I want the process
>>> to look like this (for privacy):
>>> The client first connects anonymously. If the router has
>>> a list of accepted providers that the user has to have
>>> an account at, the client tells the router which one of
>>> those he use and asks for a secure tunnel to that
>>> provider (that is verified, using SSL or similiar) for
>>> auth. The router only gets to know the provider and if
>>> the user authenticated successfully, and preferably the
>>> client then connects to a VPN from that provider (not
>>> one provided by the router). If it is a corporate
>>> network or similiar (we can be pretty sure this won't
>>> only be used for open networks), the client demands that
>>> the router identifies itself before it provides it's
>>> credentials (even if it's using SRP for auth, the
>>> username can be used for tracking otherwise by imitating
>>> the SSID).
>>>
>>> For routers where the owner don't care about what the
>>> users does at all, the router owner simply wouldn't set
>>> up any VPN or similiar. On these networks, the client
>>> would passively notify the user that no trusted proxy of
>>> any kind is used and that the router owner therefore
>>> could possibly spy on the traffic (classic "insecure
>>> network" warning).
>>>
>>> Devices that don't support OpenWireless will just see
>>> good old WiFi traffic, some of it which is a bit wierd
>>> (WiFi Direct is an official modification/extension of
>>> the regular WiFi protocols) and some SSID:s for WPA2
>>> protected networks.
>>>
>>> ---
>>>
>>> So that was my ideas for tonight. The best of all with
>>> this approach is that we need NO hacking of any wireless
>>> protocols, "just" of client and router software.
>>>
>>> --- If everybody is thinking alike, then somebody isn't
>>> thinking // Stupidity is a renewable resource
>>>
>>>
>>> On Thu, Nov 1, 2012 at 8:12 PM, Todd Freeman
>>> <todd at chiwifi.net <mailto:todd at chiwifi.net>> wrote:
>>>
>>> I forgot to mention, radius and openID are separate,
>>> but linked, because almost all wifi devices work
>>> with wpa2-enterprise, which uses radius to auth and
>>> allows you to set things like speed limits. I want
>>> to link it to the openid so that you have an open
>>> and public auth system that is also secure enough to
>>> use for financial transactions. That is also why the
>>> CA is important, I envision that eventually when
>>> businesses want to do something with the OpenIDs,
>>> they will want to do it over SSL, and personally, I
>>> trust running my own CA much more then getting certs
>>> from verisign if activists are going to use it for
>>> things like SSL VPN to their cellphone. Since
>>> the back-end is ldap we should be able to
>>> arbitrarily add any info field that we want.
>>>
>>> ------------------------------------------------------------------------
>>> *From: *"Todd Freeman" <todd at chiwifi.net
>>> <mailto:todd at chiwifi.net>>
>>> *To: *tech at srv1.openwireless.org
>>> <mailto:tech at srv1.openwireless.org>
>>> *Sent: *Thursday, November 1, 2012 1:48:31 PM
>>>
>>> *Subject: *Re: [OpenWireless Tech] Hello World
>>>
>>> Sorry I may have glossed over my version a bit, This
>>> is a basic idea of what I am setting up. It is much
>>> more complicated the wireless in the developing world.
>>>
>>> http://chiwifi.net/Diagram1.png
>>>
>>> What that does not show is the ldap and certificate
>>> authority that I just added, which would work as the
>>> backend for radius.
>>>
>>> So the basic idea is this, To sign up for service
>>> all you need to do is be in range of the network (or
>>> via the website), login to it as if it were an open
>>> network which takes you to a captive portal, the
>>> captive portal allows you to sign up for an account
>>> on the wifi network, which includes an email
>>> account. Thus the sign up process allows users to be
>>> completely anonymous while still having a
>>> un-spoofable permanent ID on the wifi network, and
>>> because that ID is an openID, it can be integrated
>>> with 3rd party services easily. So you can tie real
>>> good and services locally to this ID, and use it at
>>> local businesses for bartering or bitcoin exchange.
>>> All while remaining just as anonymous as cash. The
>>> possibilities are really endless there.
>>>
>>> So the purpose is not just free wifi, but to
>>> integrate wifi into peoples everyday business, this
>>> allows it to take hold quickly as well as build
>>> communities because people will be using it for
>>> other services if they want to.
>>>
>>> Thus far it is setup like the, the Certificate
>>> Authority is running on Centos 6, using
>>> http://pki.fedoraproject.org
>>> The ldap server is also centos 6, running
>>> http://directory.fedoraproject.org
>>> The radius server has not been setup yet, the DNS
>>> cloud is running powerDNS and I have not been able
>>> to get through openWISP enough to get the captive
>>> portal running. Unfortunately I am not a programmer.
>>> I am planning to use http://www.packetizer.com for
>>> the openID server.
>>>
>>>
>>> There is currently 1 tower up. and the datacenter it
>>> is currently at is donating 1gbit of bandwidth. I
>>> also have 2 /64's of IPv6 addresses, so the plan is
>>> to have the clients be dynamically assigned ipv6
>>> addresses. With optional static IPs for servers. So
>>> when I say the issue I have been having is with the
>>> auth, I mean the whole system. I am not using
>>> something very simple like a shared secret WPA2.
>>> Thoughts ?
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From: *"Gj" <fibreguy42 at gmail.com
>>> <mailto:fibreguy42 at gmail.com>>
>>> *To: *"Natanael" <natanael.l at gmail.com
>>> <mailto:natanael.l at gmail.com>>
>>> *Cc: *"Todd Freeman" <todd at chiwifi.net
>>> <mailto:todd at chiwifi.net>>,
>>> tech at srv1.openwireless.org
>>> <mailto:tech at srv1.openwireless.org>
>>> *Sent: *Thursday, November 1, 2012 1:23:33 PM
>>> *Subject: *Re: [OpenWireless Tech] Hello World
>>>
>>> Good to see I'm not alone here either and thanks to
>>> SaschaM for the heads up :)
>>>
>>> Openwrt is a good OSS wifi router firmware starting
>>> point with wide decice support and one that hasn't
>>> gone the closed path of others eg meraki (was MIT
>>> roofnet istr before the vc's demanded their pound of
>>> flesh)
>>>
>>> I like the android app idea Tom - never having
>>> looked at iPhone I wonder what's involved with
>>> creating and equivalent iOS app?
>>>
>>> Guy
>>>
>>> Sent from my iPhone
>>>
>>> On 1 Nov 2012, at 13:45, Natanael
>>> <natanael.l at gmail.com <mailto:natanael.l at gmail.com>>
>>> wrote:
>>>
>>> It was a bit more active for about a month, a
>>> year ago. Let's hope it wakes up again!
>>>
>>> By the way, now that Android has support for
>>> automatic WiFi Direct service
>>> announcement/detection/connection (based on UPNP
>>> and/or Bonjour), we could build something on top
>>> of that. AFAIK all it takes is a firmware
>>> upgrade for systems with ordinary recent WiFi
>>> chips to use it, so I imagine routers should be
>>> able to support it as long as the driver makers
>>> added support for it.
>>>
>>> IMHO that would be the "least messy" solution. A
>>> router could simply announce it's support for
>>> the "OpenWireless hotspot protocol" to other
>>> WiFi Direct devices.
>>>
>>> On Thu, Nov 1, 2012 at 2:39 PM, Todd Freeman
>>> <todd at chiwifi.net <mailto:todd at chiwifi.net>> wrote:
>>>
>>> I am just glad I am not the only person on
>>> this list, the site is pretty sparse on
>>> community info.
>>>
>>>
>>> On 11/01/2012 04:07 AM, Guy Jarvis wrote:
>>>
>>> testing please ignore
>>>
>>>
>>> _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org <mailto:Tech at srv1.openwireless.org>
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>>
>>> _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org
>>> <mailto:Tech at srv1.openwireless.org>
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>> _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org
>>> <mailto:Tech at srv1.openwireless.org>
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>>
>>> _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org
>>> <mailto:Tech at srv1.openwireless.org>
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>> _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org
>>> <mailto:Tech at srv1.openwireless.org>
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>
>>
>> _______________________________________________
>> Tech mailing list
>> Tech at srv1.openwireless.org
>> <mailto:Tech at srv1.openwireless.org>
>> https://srv1.openwireless.org/mailman/listinfo/tech
>>
>
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org <mailto:Tech at srv1.openwireless.org>
> https://srv1.openwireless.org/mailman/listinfo/tech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20121102/f58508cc/attachment.html>
More information about the Tech
mailing list