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> 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
http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org