[OpenWireless Tech] Hello World

Fri Nov 2 02:50:17 PDT 2012

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>:

> 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>:
>
>>  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> 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>
>>> *To: *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>
>>> *To: *"Natanael" <natanael.l at gmail.com>
>>> *Cc: *"Todd Freeman" <todd at chiwifi.net>, 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> 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> 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 listTech at srv1.openwireless.orghttps://srv1.openwireless.org/mailman/listinfo/tech
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tech mailing list
>>>> Tech at srv1.openwireless.org
>>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>>
>>>>
>>>   _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>>
>>> _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>> _______________________________________________
>>> Tech mailing list
>>> Tech at srv1.openwireless.org
>>> https://srv1.openwireless.org/mailman/listinfo/tech
>>>
>>>
>>
>>
>> _______________________________________________
>> Tech mailing list
>> 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/aa5bb04f/attachment.html>