Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

[Users] Securing wireless networks through IPsec

From: Per von Zweigbergk <pvz(at)e.kth.se>
Date: Tue Apr 29 2003 - 20:58:56 EDT


#########
First of all, let me apologise for the length of this e-mail. My actual question is at the of the e-mail, the rest is a discussion of different methods to secure wireless networks. My actual question can be found below a row of *******'s.
#########

Hello.

I'm going to be deploying a wireless network. The network isn't going to transport top secret information or anything, but still all the options I have researched have come up lacking in one way or another. After all, the network doesn't really require encryption. What it needs is a good way to authenticate users.

I'm going to start from the simplest solution involving wireless networks and work my way upwards to more and more secure solutions.

DISCLAIMER: I also must point out that I'm not a cryptographer nor a security expert, but that I've done my best to understand the bigger picture behind network security.

  1. Use only the security features existing in 802.11b base stations.

The security features in 802.11b are more of deterrents than anything.

First of all, you can set your network to be a "closed network". This makes the base station simply ignore any requests to associate with the network unless the network name is specified explicitly. The security benifits of this setup are completely nonexistent, since the network name is sent in plaintext with every single packet anyway.

Then, you can activate MAC address control. While this effectively acts as a deterrent, since the MAC address is simply sent over the air, one can just spoof ones own MAC address in order to gain access.

Do you need help?X

Then you can activate WEP. WEP contains cryptographic weaknesses, that I won't even pretend to understand in detail. I'll however try to express what little I know. It contains numerous problems.

  • Weak initiation vectors
  • A weakness with the string->hexadecimal hash used by many vendors, effectively reducing the keyspace to 21 bits.
  • Since keys are reused, you can flip bits in a packet and reinject the packets generating "real" traffic on the network.
  • Also, from what I've understood, knowing the plaintext of one message, exposes the other encrypted message when the key is reused, and also the WEP key.

The first two can be overcome, the first by patching the firmware of all stations on the network (I think), the second by not using the vendor-provided applications to hash passwords to hexadecimal hashes, and instead use a better third-party program.

The third cannot be overcome to my knowledge, except by rotating keys often enough for initialisation vectors not to be re-used.

However, the largest flaw with WEP is its key management. A key leaks, you have to change the key on all systems, and you have no way to track the leaked key.

My assessment is that WEP is not an insurmountable barrier to get past for the determined cracker, even at long key lengths. It is in fact also very susceptible to social engineering, especially in large networks.

This rules out the access control methods commonly provided by wireless access points.

2. Use software to secure the link further.

2.1. Captive portals

Do you need more help?X

Whenever an unauthenticated user attempts to log on to a network, he is presented with a web page asking him to log in to continue using the network. This approach however is, from what I've understood, far from perfect. It's susceptible both to man-in-the-middle attacks, as well as IP hijacking.

2.2. VPN (IPsec tunnels, PPTP, PPPoE, CIPE, PPP over SSH, etc)

This seems like a good option. All clients connect to a central server on the network with an encrypted and authenticated connection. However, what about communication between two hosts?

Here there are two options.

2.2.1. Use unsecured IP to communicate between hosts on the same subnet

This is clearly unacceptable. An intruder may break into a host on the network, and piggyback on it's VPN tunnel in order to get into the trusted network. This places the point of intrusion on any one of perhaps hundreds of laptops, one of which may be running an unpatched version of some software or be backdoored.

2.2.2. Refuse all IP traffic that's not coming through the VPN

This is finally becoming acceptable security-wise. But what's happening to the traffic on the network? It's going to the gateway, becoming decrypted, re-encrypted and sent back. This is an unneccecary waste of backbone bandwidth, as well as CPU time on the gateway. (This is the method described in your FAQ from what I've understood.)

Can we help you?X

2.3 IPsec in "transport mode" rather than tunnels

This is what I'm trying to achieve. It has all the advantages of point 2.2.2, as well as fixing the issue with wasted system resources.

In transport mode, from what I've understood, the packets are sent as normal using IP without any tunnels, but are encapsulated in order to authenticate and encrypt the packet.

  • Now for my question **************************

I have found very little information regarding IPsec in transport mode. There are a few issues that have to be ironed out.

Is there any software, that together with FreeS/WAN on the Linux gateway, runs on Windows XP and does IPsec in transport mode? Also, in order for this not to become configuration hell, is there any tool to automatically negotiate keys between these hosts?

Failing that, it's maybe a special case of opportunistic tunnelling I'm looking for, with one machine per tunnel, but here again the operating system is an issue. Windows XP software supporting FreeS/WAN opportunistic tunneling?

I'd also appreciate comments on my analysis above. After all, it could be useful to someone else.

Thank you in advance!

-- 
Per von Zweigbergk 

_______________________________________________
Users mailing list
Users@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
Received on Thu May 1 15:24:57 2003
Can't find what you're looking for?X

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 13:01:28 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library