[HamWAN PSDR] How does client authentication work?
Bart Kus
me at bartk.us
Mon Mar 18 01:07:40 PDT 2013
OK, one more point since this problem is eating at my very soul.
A great alternative for the OVPN tunnel thing might be IPSec(AH) in
tunnel mode between the STA and AP. Roaming would be supportable by
configuring the STA peer to be an anycast IP that's present on all
sector routers. Each sector would configure peers for each of its DHCP
range IPs? Authentication via certificates would take care of the
rest. At least that would provide a tunnel you can't mess with, and
without encryption, between STA and AP. We still lose
multicast/broadcast, but at least it's IP over IP, not IP over TCP/IP
like in the OVPN case. And the multicast loss is restricted to sector
airtime only. Multicast can still do optimizations on the backbone
itself so that the PtP links aren't saturated.
I'm not sure if this'll work out with the certs and all on MTs. Crossing
fingers.
Come to think of it, since the lower layer IPs in such a setup would be
for air-link transit only they don't need to be out of 44-space. Or,
they can be 44-space and just re-used on every sector and not announced
beyond the air interface. Question becomes how do you do DHCP in such
an environment. I suppose we could abandon DHCP and just hand out 1
static/user, but then that over the air subnet gets huge, as does the
number of IPsec peers the sectors would need to have configured. Except
what's this, the "address" value for IPsec peer definitions is actually
a subnet! And there's an option so the sectors do NOT send out the
initial contact, so that prevents flooding. The STAs can do initial
contact. 127/8 might be a good over the air subnet to use on each
sector. This network is extremely unlikely to conflict with any other
private network anyone is using. The MTs don't use it internally, and
should be fine to use it on a real interface. Plenty of addresses to
hand out statics from. Avoids the DHCP problem, since any associated
joker can put up a DHCP server on a sector. Is there some DHCPsec spec
I'm not aware of? :) Upon further reflection, over-the-air would be
really well served by IPv6 link-local IPs, but I don't think IPsec on
MTs supports IPv4-over-IPv6.
All this rambling needs some serious testing.
--Bart
On 3/17/2013 10:12 PM, Bart Kus wrote:
> So here's the thing, I can't seem to find a way to do 802.1x or
> 802.11i or WPA2-EAP or EAP-TLS, whatever you wanna call it, without
> the gear actually setting up an encrypted tunnel between the STA and
> the AP. I can't see a way to use a null cipher here or to disable the
> tunnel creation phase after the authentication has succeeded. We
> can't even say "OK we'll publish the keys" because the keys are
> dynamically generated. Here's a good picture of EAP-TLS:
>
> http://cwne88.files.wordpress.com/2012/08/eap-tls.gif
>
> And here's the 4-way handshake details:
> http://en.wikipedia.org/wiki/IEEE_802.11i-2004#The_Four-Way_Handshake
>
> If we could just stop at step 6 or 7, life would be grand! This is
> looking impossible, sirs.
>
> One more thing to consider is we can also setup tunnels between the
> STAs and APs. In fact, if we use OVPN tunnels, I know for a fact
> those can run with null ciphers. The story of how they do cert
> authentication might be a little weird though. OVPN may or may not
> integrate with the RADIUS here. Also, those tunnels would be over
> TCP, so that sucks. There are other tunneling schemes in the MT might
> may be more appropriate. The other crappy thing about PtP-only
> tunnels is it does not do well with broadcast or multicast traffic.
> WPA2-EAP handles this by setting up a 2nd key as a "group cipher" and
> all broadcast/multicast messages use that 2nd crypto scheme.
>
> That's as far as I got today. Still need to finish reading the EAP
> RFC, and read the EAP-TLS RFC, and then read the IPsec RFC(s). So
> much work! I don't why the IEEE married encryption to authentication
> in WPA. :( Maybe cuz WEP was such a huge embarrassment.
>
> --Bart
>
>
> On 3/17/2013 7:39 PM, steve monsey wrote:
>> One thing I would keep in mind is how much time would have to be
>> spent enforcing some of these strategies. It would be a way of
>> eliminating some of them if the team could only spend "ham time" to
>> it. So take one step back and figure out your policy and time
>> commitment and the proper technical protocol will become apparent. I
>> think!
>>
>> Steve
>>
>> On Mar 17, 2013, at 2:18 PM, "Cory (NQ1E)" <cory at nq1e.hm
>> <mailto:cory at nq1e.hm>> wrote:
>>
>>> Welcome to my world ;)
>>>
>>> As I've expressed in the past, this is one of the challenges that
>>> makes me excited about this project. Making a network secure
>>> without encryption isn't really something that's been done before.
>>> Several protocols do support authentication and integrity without
>>> secrecy, but I suspect they were only implemented for things like
>>> compatibility testing. The trick is going to be finding out how to
>>> take advantage of that in a way that doesn't make it too complicated
>>> for end-users to implement.
>>>
>>> Because we're not going to encrypt traffic, using anything password
>>> based won't do. A shared secret would be okay except that it's hard
>>> to control, change and keep secret (this is the method HSMM-MESH and
>>> NW-MESH currently use to trust the OLSR announcements of other
>>> users). I believe that the best option by far would have to be a
>>> solution based on public/private key pairs.
>>>
>>> Here are the options I know of based on layers of the OSI model:
>>>
>>>
>>> Layer 6: SSL/TLS & SSH
>>>
>>> It seems to me that SSH was designed with secrecy as the main goal,
>>> while integrity and trust were simply slapped on as an afterthought.
>>> While it appears to be possible to use SSH with null (no)
>>> encryption, I haven't been able to find any client or
>>> server implementations that support it without code modifications.
>>>
>>> From the start, SSL was designed with the idea that you need a way
>>> to establish trust with a server you may be connecting to for the
>>> first time. The actual encryption part of the protocol is modular
>>> and it's easy to setup a server to use "null" as its cipher.
>>> Unfortunately for us, most web browsers cripple support for null
>>> ciphers because they assume nobody would ever need that and they
>>> don't want users connecting to "misconfigured" servers. So far I've
>>> only found two browsers that support turning null ciphers back on in
>>> their advanced settings (Firefox and Opera). A little known/used
>>> feature of SSL/TLS is mutual authentication. This is where the
>>> client also has a certificate and private key so that trust can be
>>> established in both directions. My testing has confirmed that this
>>> works, but it may be too complicated to setup for both the client
>>> and the server.
>>>
>>>
>>> Layer 3: IPSec
>>>
>>> Similar to SSL, IPSec has the ability to provide authentication and
>>> integrity to traffic without hiding its payload with encryption.
>>> This is the area where my research is currently focused. I want to
>>> be able to prove that it can be done in a way that's hopefully easy
>>> for users to understand and implement. The major advantage to this
>>> method is that it's configured at the OS level and any client or
>>> server program would be able to take advantage of it.
>>>
>>>
>>> Layer 2: 802.1x
>>>
>>> With the methods above, someone could still
>>> generate illegitimate traffic over at least one RF portion of
>>> network. In order to protect the link layer, we could use 802.1x.
>>> Unfortunately, it only provides authentication and does nothing
>>> about integrity. This means that without encryption, it would be
>>> trivial to impersonate another user on the link layer who is already
>>> authenticated.
>>>
>>>
>>> At this point, I believe that using 802.1x on the RF links and
>>> enforcing rules that only allow IPSec signed traffic to pass would
>>> meet the objectives. There's also the added benefit that IPSec
>>> traffic maintains its signature throughout the life of the packet,
>>> so rogue users could be identified regardless of where their traffic
>>> originated.
>>>
>>> While this is an area where my geekdom shines, I do not pretend to
>>> know it all. Therefore I definitely encourage conversation on these
>>> topics as long as it remains constructive. What do you think about
>>> these approaches?
>>>
>>> -Cory
>>> NQ1E
>>>
>>>
>>>
>>> On Sun, Mar 17, 2013 at 1:15 PM, Bart Kus <me at bartk.us
>>> <mailto:me at bartk.us>> wrote:
>>>
>>> Now taking proposals. It's turning out to be a non-trivial
>>> thing to implement in a way that's not hijackable, and only
>>> allows registered hams onto the network, while not using
>>> encryption in prohibited ways.
>>>
>>> Thoughts?
>>>
>>> --Bart
>>>
>>>
>>> _______________________________________________
>>> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130318/a26ef9da/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 93096 bytes
Desc: not available
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130318/a26ef9da/attachment.gif>
More information about the PSDR
mailing list