<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">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.04070401.01080807@bartk.us"><br>
<br>
And here's the 4-way handshake details:
<a 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 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>