[HamWAN PSDR] How does client authentication work?

[steve monsey]

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!

Steve

On Mar 17, 2013, at 2:18 PM, "Cory (NQ1E)" <cory at nq1e.hm> wrote:

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

_______________________________________________
PSDR mailing list
PSDR at hamwan.org
http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130317/b889578b/attachment.html>