On 03/01/13 22:30, the mail apparently from [email protected]
included:
On 03/01/13 20:03, the mail apparently from [email protected]
included:
On 03/01/13 15:08, the mail apparently from [email protected]
included:
solutions in parallel without spending so much energy knocking down
other people's ideas, more progress will be made. That's not to say
These are old ideas, and knocking them down is as easy as knocking WEP
down. They are suboptimal, and people should be made aware of the HUGE
What do you mean by comparing VPN to WEP, that it is insecure like WEP?
It is not.
VPN is a suboptimal solution like WEP. A (rather beautiful) hack, like
WEP.
Words like "suboptimal" and "hack" are not adding anything to
understanding the issues: they're, well, just, like your opinion, man.
When your VPN concatenator no longer accepts your password you will
understand why the VPN is suboptimal: not everyone can use one. It is a
very complex setup.
There's nothing inherently complex about it, I can install openvpn on my
OpenWRT router and if someone hasn't already can make a local web
interface to cut and paste client certs around from inside my home
network to set it up on client devices as a one-off.
Any certs are selfsigned by the router / "VPN server", there's no
central coordination needed.
You haven't shown anything more optimal that delivers the same result
EAP-TLS provides the same result. Actually, it provides something better
No, I mean the result that the AP operator can avoid liability for what
his clients are doing.
http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol
just provides for clientside certs, that is nice in terms of protecting
clients from each other, but it's not addressing liability.
than IPsec: it provides link-level security. If you don't know what that
means, then I really can't show anything more.
and I don't agree it is a hack layering the encryption like that.
I think its a hack if you expect everyone to do what you have been
provided by someone else: your corporate VPN.
You can always disable RSN in my solution. You can always have your
corporate VPN in my solution.
In your solution, you can't. Because its a hack (an old hack.)
RSN as in "Robust Security Network" == WPA2? VPN encryption coverage
from client to his VPN server means the client doesn't need the
obfuscation from WPA any more. The AP operator may want it to restrict
users but you're missing something important about the topic at hand -->
...
Do you see now that might help encourage AP owners to allow VPN-only
connections from random clients? Or, do you have a better scheme that
delivers the same kind of result?
I still don't know what you mean by "VPN-only". So no one should be able
to use SSH? They shouldn't be able to use IPsec ESP? That isnt
OpenWireless. If my grandma can't use SSH, or some other protocol, on her
network because you decided that only VPN is allowed, that is a good
indication your solution is a hack.
No the proposal is the same AP can at least use WPA at the same time, if
you have a PSK, meaning a single home router will do what people want
today, WPA2 for their local network, and offer this on the side. If you
want to run IPSec or anything else it can work out of its scope too.
The point is that if you associate without IPSEC / WPA / etc
credentials, it will accept your client unencrypted but won't route any
packet that is not UDP and part of a VPN connection action.
So there's at once a very open grant of use, that anyone can walk up and
use it without identity or credentials at all, but at the same time the
very strong restriction the usage is only to get them as far as their
VPN server / home router running a VPN server. From that point, they go
out on the internet "under their own name".
Because an encrypted VPN link is mandatory in that "default" mode,
clients are protected from each other and from a malicious AP... and the
AP operator is protected from whatever the clients are doing.
-Andy
_______________________________________________
Tech mailing list
[email protected]
https://srv1.openwireless.org/mailman/listinfo/tech
