<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><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 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 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>
______________________________<u></u>_________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/<u></u>mailman/listinfo/psdr_hamwan.<u></u>org</a><br>
</blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>PSDR mailing list</span><br><span><a href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a></span><br><span><a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a></span><br>
</div></blockquote></body></html>