18 Apr
2014
18 Apr
'14
2:35 p.m.
Unfortunately, none of the wifi security protocols (including WPA with
802.1x) support an authentication-only mode. They all require the traffic
to be encrypted as private and unreadable to others. There's also not a
whole lot we can do about that since these protocols are baked into the
actual wifi chipsets and cannot be modified without a great deal of
resources.
Since there is no ideal way to both secure layer 2 and remain legal, HamWAN
solves this problem at layer 3 by taking advantage of the
authentication-only features of IPSec called IPSec(AH) or Authentication
Header. When two routers are connected to each other over an RF link, they
use the link-local non-routable address space (169.254.0.0/16) on the air
so they can speak to just each other. However, those IPs only listen for
IPSec(AH) traffic when authenticated with a valid certificate. They can
then create a cleartext non-private "VPN" tunnel that allows them to pass
traffic for the real network between themselves. Anyone can monitor this
traffic, which is good. However, it cannot be successfully altered in
transit or spoofed by pirates, which is also good. :)
-Cory NQ1E
Radio Hacker
On Thu, Apr 17, 2014 at 11:53 PM, Don Fanning <don(a)00100100.net> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> I correct myself. 802.1X would be the lower level protocol/standard and
> Radius/Diameter is the layer 7 application. Again this could be intertied
> to LDAP or Active Directory for seamless authentication and the potential
> to have single sign-on.
>
>
> On Thu, Apr 17, 2014 at 11:29 PM, Don Fanning <don(a)00100100.net> wrote:
>
> > No, the communication is the entire content of the packet. Again, you
> > can't pick and choose what parts of the law apply and what doesn't. It
> > would be like saying you can do Phone transmissions in the CW portion of
> > the band because it's digital. Your argument continues to try and warp
> the
> > law as written when it clearly states otherwise.
> >
> > The ARRL has already dropped their argument regarding link layer
> > encryption by using the following overarching rule:
> >
> > *Part 97 : Sec. 97.105 Control operator duties (a) The control operator
> > must ensure the immediate proper operation of the station, regardless of
> > the type of control*
> >
> > This overrides 97.113 as .113 has one of those "except as otherwise
> > specified under this part..." sentences in the subsection preamble.
> >
> > And I've already described a method of authentication using WPA and
> PKI...
> > some people know it as RADIUS authentication which is good enough for
> many
> > corporations to authenticate users to their networks. This occurs at a
> > lower level than SSL but higher than link level. This would be just to
> > validate that you are legitimate to access the network.
> >
> > SSL is not a magic bullet. Last week that was proven apparent as many of
> > us have had to patch millions of servers against the Heartbleed
> > vulnerability which involved certain versions of OpenSSL. And if that
> > doesn't scare you, there is always Firesheep.
> >
> > Since authentication should start at the network level and not the
> session
> > layer due to 97.105 to ensure that you are authorized to transmit and I
> am
> > authorized to relay your traffic, using LOTW or other higher level means
> of
> > security does fall subject to 97.113.
> >
> >
> >
> > On Thu, Apr 17, 2014 at 8:38 PM, <lleachii(a)aol.com> wrote:
> >
> >> (Please trim inclusions from previous messages)
> >> _______________________________________________
> >> Don,
> >>
> >> You mentioned a sernario where 802.11 itself is encrypted, I disagree
> >> that's legal (see below). I'm also under the impression that, in
some
> >> cases, the return packet may be a 3rd party communication (if you want
> to
> >> discuss this from Layer 3); but I won't get into that, since I
purposely
> >> stuck to Layer 1 to formulate my theory.
> >>
> >> The "communication" here is an 802.11 frame (which happens to
contain an
> >> Ethernet [802.3] frame, which contains an TCP/IP packet). So, at the
> >> 'nitty-gritty' of RF, I'm sending you an 802.11 frame by DSSS or
OFDM -
> by
> >> Part 97, I can't obfuscate the 802.11 WLAN frames (so encrypted access
> >> points may be a no-no here, but ARRL even says that the code can be
> >> 'published' and they believe that solves the closed access point
issue
> - I
> >> suppose analogous to someone not knowing the PL tone to transmit, if you
> >> will; but I don't 100% agree).
> >>
> >> I'm 100% aware some stations may disagree with that notion; but as far
> as
> >> I'm concerned, I can sniff 802.11 frames all day, if I can determine
the
> >> callsign somewhere, tell if it's 802.11, tell the device MACs and that
> it's
> >> an Ethernet frame (even even more, that it's
> ICMP/TCP/UDP/GRE/IPENCAP/etc.),
> >> we're within the scope of the Part 97.
> >>
> >>
> >> -KB3VWG
> >>
> >> _________________________________________
> >> 44Net mailing list
> >> 44Net(a)hamradio.ucsd.edu
> >> http://hamradio.ucsd.edu/mailman/listinfo/44net
> >>
> >
> >
>