[HamWAN PSDR] Traffic protection without encryption

Fri Feb 22 01:29:54 PST 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130222/cd3fbb16/attachment.html>