[HamWAN PSDR] Traffic protection without encryption

Fri Feb 22 07:03:04 PST 2013

Yes, that is how a lot of organizations use it. One of the issues is with
small gadgets that do not have that much sophistication in their OS. An
echo link gadget probably does not have the facility to do a certificate.

Steve

On Feb 22, 2013, at 1:30 AM, Benjamin Krueger <ben.krueger at gmail.com> wrote:

This would work fine as well.

On Fri, Feb 22, 2013 at 12:14 AM, Cory (NQ1E) <cory at nq1e.hm> wrote:

> When you use someone's public key to establish a secure connection with
> them, you need a way to verify that it belongs to the party you intend and
> not an imposer.  One way to do that is to make the public keys available
> ahead of time via a trusted source (such as DNSSEC).  However, certificates
> are an alternative way of doing that without communicating in advance or
> with any other online system.  Each party trusts one or more root
> certificate authorities and the CAs vouch for someone by signing their
> public key.  Each host knows that "if the root trusts who I'm talking to,
> they must be legit".  A certificate is simply a public key with
> identifying information which is then signed by a trusted third party.
>
>
>
> On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger <ben.krueger at gmail.com>wrote:
>
>> The problem isn't generating keys and certificates, but distributing them
>> so that hosts which are strangers have a way to authenticate each other. So
>> far dnssec looks like a candidate. Check out the rfc for opportunistic
>> encryption (rfc 4322).
>>
>> On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <cory at nq1e.hm> wrote:
>> >
>> > 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 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
>> >>
>> >
>> >
>> > _______________________________________________
>> > PSDR mailing list
>> > PSDR at 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
>>
>>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>
>

-- 
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/20130222/e7a83ceb/attachment.html>