<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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.<br>
<br>
--Bart<br>
<br>
<br>
On 02/22/2013 02:17 PM, Benjamin Krueger wrote:<br>
</div>
<blockquote
cite="mid:CAMcW5DqGGwx39s_T0YaYyj4WCmjh3oMtqjwXV-h=oeYV75pjSg@mail.gmail.com"
type="cite">
<div dir="ltr">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.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Feb 22, 2013 at 7:03 AM, steve
monsey <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:stevewa206@gmail.com" target="_blank">stevewa206@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>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. <span class="HOEnZb"><font color="#888888"><br>
<br>
Steve</font></span></div>
<div>
<div class="h5">
<div><br>
On Feb 22, 2013, at 1:30 AM, Benjamin Krueger <<a
moz-do-not-send="true"
href="mailto:ben.krueger@gmail.com"
target="_blank">ben.krueger@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">This would work fine as well.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Feb 22, 2013 at
12:14 AM, Cory (NQ1E) <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:cory@nq1e.hm" target="_blank">cory@nq1e.hm</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<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>
<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
moz-do-not-send="true"
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>
<div>
<p dir="ltr">On Feb 21, 2013
8:31 PM, "Cory (NQ1E)" <<a
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:PSDR@hamwan.org"
target="_blank">PSDR@hamwan.org</a><br>
>> <a
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:PSDR@hamwan.org"
target="_blank">PSDR@hamwan.org</a><br>
> <a
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:PSDR@hamwan.org"
target="_blank">PSDR@hamwan.org</a><br>
<a moz-do-not-send="true"
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>
</div>
</div>
<br>
_______________________________________________<br>
PSDR mailing list<br>
<a moz-do-not-send="true"
href="mailto:PSDR@hamwan.org"
target="_blank">PSDR@hamwan.org</a><br>
<a moz-do-not-send="true"
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>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Benjamin<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>PSDR mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:PSDR@hamwan.org" target="_blank">PSDR@hamwan.org</a></span><br>
<span><a moz-do-not-send="true"
href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org"
target="_blank">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
PSDR mailing list<br>
<a moz-do-not-send="true" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a><br>
<a moz-do-not-send="true"
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>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Benjamin<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
PSDR mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a class="moz-txt-link-freetext" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>