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