OK, one more point since this problem is eating at my very soul. A great alternative for the OVPN tunnel thing might be IPSec(AH) in tunnel mode between the STA and AP. Roaming would be supportable by configuring the STA peer to be an anycast IP that's present on all sector routers. Each sector would configure peers for each of its DHCP range IPs? Authentication via certificates would take care of the rest. At least that would provide a tunnel you can't mess with, and without encryption, between STA and AP. We still lose multicast/broadcast, but at least it's IP over IP, not IP over TCP/IP like in the OVPN case. And the multicast loss is restricted to sector airtime only. Multicast can still do optimizations on the backbone itself so that the PtP links aren't saturated. I'm not sure if this'll work out with the certs and all on MTs. Crossing fingers. Come to think of it, since the lower layer IPs in such a setup would be for air-link transit only they don't need to be out of 44-space. Or, they can be 44-space and just re-used on every sector and not announced beyond the air interface. Question becomes how do you do DHCP in such an environment. I suppose we could abandon DHCP and just hand out 1 static/user, but then that over the air subnet gets huge, as does the number of IPsec peers the sectors would need to have configured. Except what's this, the "address" value for IPsec peer definitions is actually a subnet! And there's an option so the sectors do NOT send out the initial contact, so that prevents flooding. The STAs can do initial contact. 127/8 might be a good over the air subnet to use on each sector. This network is extremely unlikely to conflict with any other private network anyone is using. The MTs don't use it internally, and should be fine to use it on a real interface. Plenty of addresses to hand out statics from. Avoids the DHCP problem, since any associated joker can put up a DHCP server on a sector. Is there some DHCPsec spec I'm not aware of? :) Upon further reflection, over-the-air would be really well served by IPv6 link-local IPs, but I don't think IPsec on MTs supports IPv4-over-IPv6. All this rambling needs some serious testing. --Bart On 3/17/2013 10:12 PM, Bart Kus wrote:
So here's the thing, I can't seem to find a way to do 802.1x or 802.11i or WPA2-EAP or EAP-TLS, whatever you wanna call it, without the gear actually setting up an encrypted tunnel between the STA and the AP. I can't see a way to use a null cipher here or to disable the tunnel creation phase after the authentication has succeeded. We can't even say "OK we'll publish the keys" because the keys are dynamically generated. Here's a good picture of EAP-TLS:
http://cwne88.files.wordpress.com/2012/08/eap-tls.gif
And here's the 4-way handshake details: http://en.wikipedia.org/wiki/IEEE_802.11i-2004#The_Four-Way_Handshake
If we could just stop at step 6 or 7, life would be grand! This is looking impossible, sirs.
One more thing to consider is we can also setup tunnels between the STAs and APs. In fact, if we use OVPN tunnels, I know for a fact those can run with null ciphers. The story of how they do cert authentication might be a little weird though. OVPN may or may not integrate with the RADIUS here. Also, those tunnels would be over TCP, so that sucks. There are other tunneling schemes in the MT might may be more appropriate. The other crappy thing about PtP-only tunnels is it does not do well with broadcast or multicast traffic. WPA2-EAP handles this by setting up a 2nd key as a "group cipher" and all broadcast/multicast messages use that 2nd crypto scheme.
That's as far as I got today. Still need to finish reading the EAP RFC, and read the EAP-TLS RFC, and then read the IPsec RFC(s). So much work! I don't why the IEEE married encryption to authentication in WPA. :( Maybe cuz WEP was such a huge embarrassment.
--Bart
On 3/17/2013 7:39 PM, steve monsey wrote:
One thing I would keep in mind is how much time would have to be spent enforcing some of these strategies. It would be a way of eliminating some of them if the team could only spend "ham time" to it. So take one step back and figure out your policy and time commitment and the proper technical protocol will become apparent. I think!
Steve
On Mar 17, 2013, at 2:18 PM, "Cory (NQ1E)" <cory@nq1e.hm <mailto:cory@nq1e.hm>> wrote:
Welcome to my world ;)
As I've expressed in the past, this is one of the challenges that makes me excited about this project. Making a network secure without encryption isn't really something that's been done before. Several protocols do support authentication and integrity without secrecy, but I suspect they were only implemented for things like compatibility testing. The trick is going to be finding out how to take advantage of that in a way that doesn't make it too complicated for end-users to implement.
Because we're not going to encrypt traffic, using anything password based won't do. A shared secret would be okay except that it's hard to control, change and keep secret (this is the method HSMM-MESH and NW-MESH currently use to trust the OLSR announcements of other users). I believe that the best option by far would have to be a solution based on public/private key pairs.
Here are the options I know of based on layers of the OSI model:
Layer 6: SSL/TLS & SSH
It seems to me that SSH was designed with secrecy as the main goal, while integrity and trust were simply slapped on as an afterthought. While it appears to be possible to use SSH with null (no) encryption, I haven't been able to find any client or server implementations that support it without code modifications.
From the start, SSL was designed with the idea that you need a way to establish trust with a server you may be connecting to for the first time. The actual encryption part of the protocol is modular and it's easy to setup a server to use "null" as its cipher. Unfortunately for us, most web browsers cripple support for null ciphers because they assume nobody would ever need that and they don't want users connecting to "misconfigured" servers. So far I've only found two browsers that support turning null ciphers back on in their advanced settings (Firefox and Opera). A little known/used feature of SSL/TLS is mutual authentication. This is where the client also has a certificate and private key so that trust can be established in both directions. My testing has confirmed that this works, but it may be too complicated to setup for both the client and the server.
Layer 3: IPSec
Similar to SSL, IPSec has the ability to provide authentication and integrity to traffic without hiding its payload with encryption. This is the area where my research is currently focused. I want to be able to prove that it can be done in a way that's hopefully easy for users to understand and implement. The major advantage to this method is that it's configured at the OS level and any client or server program would be able to take advantage of it.
Layer 2: 802.1x
With the methods above, someone could still generate illegitimate traffic over at least one RF portion of network. In order to protect the link layer, we could use 802.1x. Unfortunately, it only provides authentication and does nothing about integrity. This means that without encryption, it would be trivial to impersonate another user on the link layer who is already authenticated.
At this point, I believe that using 802.1x on the RF links and enforcing rules that only allow IPSec signed traffic to pass would meet the objectives. There's also the added benefit that IPSec traffic maintains its signature throughout the life of the packet, so rogue users could be identified regardless of where their traffic originated.
While this is an area where my geekdom shines, I do not pretend to know it all. Therefore I definitely encourage conversation on these topics as long as it remains constructive. What do you think about these approaches?
-Cory NQ1E
On Sun, Mar 17, 2013 at 1:15 PM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Now taking proposals. It's turning out to be a non-trivial thing to implement in a way that's not hijackable, and only allows registered hams onto the network, while not using encryption in prohibited ways.
Thoughts?
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
