[HamWAN PSDR] Traffic protection without encryption

Fri Feb 22 16:57:18 PST 2013

I don't know, without testing, whether there are issues with non-ipsec
enabled hosts communicating with ipsec enabled hosts.

On Fri, Feb 22, 2013 at 3:24 PM, Bart Kus <me at bartk.us> wrote:

>  Why provide a proxy that ultimately does nothing?  Just don't use IPSec
> on the devices that can't support it, and accept the situation.
>
> --Bart
>
>
>
> On 02/22/2013 02:17 PM, Benjamin Krueger wrote:
>
> 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
>
>
> _______________________________________________
> PSDR mailing listPSDR at hamwan.orghttp://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/eb8af586/attachment.html>