[HamWAN PSDR] How does client authentication work?

Sun Mar 17 22:12:54 PDT 2013

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130317/90442d84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eap-tls.gif
Type: image/gif
Size: 93096 bytes
Desc: not available
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20130317/90442d84/attachment.gif>