[HamWAN PSDR] Traffic protection without encryption
Bart Kus
me at bartk.us
Fri Feb 22 15:24:19 PST 2013
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
> <mailto: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 <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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 <mailto: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 <mailto:PSDR at hamwan.org>
>> >> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>> >>
>> >
>> >
>> > _______________________________________________
>> > PSDR mailing list
>> > PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>> > http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>> >
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>
>>
>>
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>>
>>
>>
>>
>> --
>> Benjamin
>> _______________________________________________
>> PSDR mailing list
>> PSDR at hamwan.org <mailto:PSDR at hamwan.org>
>> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org <mailto: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/98b87df4/attachment.html>
More information about the PSDR
mailing list