<div dir="ltr">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.<div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 10:33 PM, Benjamin Krueger <span dir="ltr"><<a href="mailto:ben.krueger@gmail.com" target="_blank">ben.krueger@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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).</p>
<div class="HOEnZb"><div class="h5">

<p dir="ltr">On Feb 21, 2013 8:31 PM, "Cory (NQ1E)" <<a href="mailto:cory@nq1e.hm" target="_blank">cory@nq1e.hm</a>> wrote:<br>
><br>
> 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.<br>


><br>
> 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.<br>


><br>
> 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 <a href="https://mutual.hamauth.com/" target="_blank">https://mutual.hamauth.com/</a>  If you have such a cert and imported it into your browser, you could try it out.  I also have one running at <a href="https://tls-test.nq1e.hm/" target="_blank">https://tls-test.nq1e.hm/</a> 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.<br>


><br>
> 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.<br>
><br>
> 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).  ;)<br>


><br>
> -Cory<br>
> *infosec geek*<br>
><br>
><br>
><br>
> On Thu, Feb 21, 2013 at 7:21 PM, Benjamin Krueger <<a href="mailto:ben.krueger@gmail.com" target="_blank">ben.krueger@gmail.com</a>> wrote:<br>
>><br>
>> 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.<br>


>><br>
>> I'm going to speak to some infosec geeks about this tonight<br>
>><br>
>> 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.<br>


>><br>
>> -- <br>
>> Benjamin<br>
>><br>
>> _______________________________________________<br>
>> PSDR mailing list<br>
>> <a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
>> <a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> PSDR mailing list<br>
> <a href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a><br>
> <a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
><br>
</p>
</div></div><br>_______________________________________________<br>
PSDR mailing list<br>
<a href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a><br>
<a href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org" target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a><br>
<br></blockquote></div><br></div>