[HamWAN PSDR] Traffic protection without encryption

[Cory (NQ1E)]

IPSec(AH) is a great solution for protecting the availability of services
on the network.  Unfortunately, it does nothing to protect layers 1 and 2
(the more important ones to the RF rules).  Arguably, only having layer 2
access to a node will not get you very much, but it's worth noting.
 Because of this 802.1x will likely be the way to go and I'm currently
investigating the details of what it would look like for our specific use
case. Short of customizing the RF spec, there's not really much else we
could do at the lower layers.

Regarding key exchange, it turns out that the ARRL already has a PKI trust
infrastructure in place.  The ARRL Logbook of the
World<http://www.arrl.org/logbook-of-the-world>service requires that
hams jump though hoops to prove
their licence identity and it issues them a certificate with their call
sign when they do.

The certificates are intended to be used for signing logbook entries, but
if you know what you're doing, there's nothing that would prevent you from
exporting the key pair and using it for other things.  A server that trusts
the ARRL root CA certificate would be able to prove the identity and call
sign of any user connecting to it with such a user cert.  I setup a test
server for this a while back and it's still up and running at
https://mutual.hamauth.com/  If you have such a cert and imported it into
your browser, you could try it out.  I also have one running at
https://tls-test.nq1e.hm/ that you may not be able to connect to because
it's also using the little known null (no) encryption cipher spec in SSL
which browsers don't support by default (it can be enabled in firefox or
opera).  This means that if the client was properly configured, we could
use SSL servers for specific services on the wireless network for
authentication, authorization and integrity without encryption.

The same rsa key pair can use used for SSH auth as well, but from my
investigations, it would require custom binaries on both the client and
server side to disable the encryption.

It's a cumbersome hurdle that we wouldn't want to make people jump through,
but if it were more popular, it could be used for just about anything.  You
should all definitely sign up for LotW just in case (since it can take a
week or two to get verified).  ;)

-Cory
*infosec geek*



On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <ben.krueger at gmail.com>wrote:

> I think we can solve a lot of our crypto-regulation problems if we explore
> IPSec in Authentication Header Transport mode. This signs every IP packet
> which gets us connection integrity, origin authentication, and replay
> protection without encrypting anything. Then we only have to take very
> basic measures to ensure folks don't intentionally or unintentionally make
> encrypted connections (over SSL, SSH, or other commonly encrypted
> protocols). The only outstanding question then is how to handle IKE (key
> exchange) in an automated way with certificates.
>
> I'm going to speak to some infosec geeks about this tonight
>
> NB: This doesn't handle initial network access authentication. That's
> still a problem to be solved, possibly with 802.1X, though that has its own
> problem since RouterOS only supports TLS-EAP which incorporates crypto.
>
> --
> Benjamin
>
> _______________________________________________
> 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/20130221/aecbb2d5/attachment.html>