[HamWAN PSDR] Traffic protection without encryption

Fri Feb 22 14:17:57 PST 2013

I suspect that for those kinds of devices, we would do well to provide them
with a proxy service they can use. It won't have any integrity guarantees,
but as long as they understand that they it should be ok.

On Fri, Feb 22, 2013 at 7:03 AM, steve monsey <stevewa206 at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> 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/b7e6a064/attachment.html>