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