<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">OK, one more point since this problem
is eating at my very soul.<br>
<br>
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.<br>
<br>
I'm not sure if this'll work out with the certs and all on MTs.
Crossing fingers.<br>
<br>
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.<br>
<br>
All this rambling needs some serious testing.<br>
<br>
--Bart<br>
<br>
<br>
<br>
On 3/17/2013 10:12 PM, Bart Kus wrote:<br>
</div>
<blockquote cite="mid:5146A256.6090608@bartk.us" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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:<br>
<br>
<img class="decoded"
alt="http://cwne88.files.wordpress.com/2012/08/eap-tls.gif"
src="cid:part1.00070907.03010208@bartk.us"><br>
<br>
And here's the 4-way handshake details: <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://en.wikipedia.org/wiki/IEEE_802.11i-2004#The_Four-Way_Handshake">http://en.wikipedia.org/wiki/IEEE_802.11i-2004#The_Four-Way_Handshake</a><br>
<br>
If we could just stop at step 6 or 7, life would be grand! This
is looking impossible, sirs.<br>
<br>
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.<br>
<br>
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.<br>
<br>
--Bart<br>
<br>
<br>
On 3/17/2013 7:39 PM, steve monsey wrote:<br>
</div>
<blockquote cite="mid:-5139503948579550169@unknownmsgid"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div>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! <br>
<br>
Steve</div>
<div><br>
On Mar 17, 2013, at 2:18 PM, "Cory (NQ1E)" <<a
moz-do-not-send="true" href="mailto:cory@nq1e.hm">cory@nq1e.hm</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Welcome to my world ;)
<div> <br>
</div>
<div style="">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.</div>
<div style=""><br>
</div>
<div style="">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.<br>
</div>
<div style=""><br>
</div>
<div style="">Here are the options I know of based on
layers of the OSI model:<br>
</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style="">Layer 6: SSL/TLS & SSH</div>
<div style=""><br>
</div>
<div style=""> 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.</div>
<div style=""><br>
</div>
<div style="">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.</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style="">Layer 3: IPSec</div>
<div style=""><br>
</div>
<div style="">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.</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style="">Layer 2: 802.1x</div>
<div style=""><br>
</div>
<div style="">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.</div>
<div style=""><br>
</div>
<div style=""><br>
</div>
<div style="">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.</div>
<div style=""><br>
</div>
<div style="">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?</div>
<div style=""><br>
</div>
<div style="">-Cory</div>
<div style="">NQ1E</div>
<div style=""><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, Mar 17, 2013 at 1:15 PM,
Bart Kus <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:me@bartk.us" target="_blank">me@bartk.us</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Thoughts?<br>
<br>
--Bart<br>
<br>
<br>
_______________________________________________<br>
PSDR mailing list<br>
<a moz-do-not-send="true"
href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a moz-do-not-send="true"
href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org"
target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>PSDR mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a></span><br>
<span><a moz-do-not-send="true"
href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a></span><br>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
PSDR mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
PSDR mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a class="moz-txt-link-freetext" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
</body>
</html>