[OpenWireless Tech] Hello World
Todd Freeman
todd at chiwifi.net
Fri Nov 2 03:02:07 PDT 2012
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20121102/28066a05/attachment.html>
More information about the Tech
mailing list