Depleting usable bandwidth since April 30, 2000
Auth Project
Out of basic need, I have started work on an authentication protocol for IP-based wireless networks. 802.11a/b/g have no real methods of authentication and this is an attempt to solve this situation until a better means is created *and* implemented by the IEEE.
802.11b networks are directly transparent to Ethernet networks, which all take place on Layer 2. This means that each wireless device has a MAC address in addition to an IP address.
Some very basic authentication models use MAC-address filtering at the layer 2 level to permit and deny access to certain wireless devices on a network. Although this does provide some security, many wireless devices allow the changing of the card's MAC address. One could simply sniff network traffic and replicate an existing MAC address to gain access to the network. This is unacceptible.
The only true way to detect wether or not a client is truly genune is to challenge the client with other information that only the server and the client would be privy to.
Our example network exists of a switched environment, where all Access Points are placed into a special VLAN. Only a Layer 3 router and a SWAP server exist in this network segment. IP addresses are DHCP'ed out to whoever asks. Private addresses behind a firewall would be ideal. Port security is enabled on the switch, denying all MAC addresses except those which are added to the table by the SWAP server.
Each client runs a piece of software which has local file access to two seperate "key files". These key files are very large (ranging from 64kB to several megabytes). Infact, they are not encryption keys, but a file of purely random data used in challenge responses. Each wireless node has a different set of key files, and the SWAP server contains many of these unique keys in its local disk as well. On a wireless node, one file exists as an authentication key from the SERVER to the CLIENT. The other file is an authentication key from the CLIENT to the SERVER.
Once the client obtains an IP address, it sends a message to the SWAP server. This message requests access to the network. The SWAP server replies with three fields of data: [Key offset] [Key data] [Challenge offset]
The Key offset is the file pointer offset of the SERVER->CLIENT key file. The data is the data that should exist in that location. A SERVER->CLIENT key file exists so it is very difficult to assume the indentity of the SWAP server. The Challenge offset is the "challenge" from the SWAP server asking what is in file offset X in the CLIENT->Server key file.
The client replies with the "ANSWER" with one field containing the result data. If this data is correct, the SWAP server adds the card in the switch port's MAC address permit table.
The SWAP server has the option of routine challenging of the node during the session, to avoid hijacks. If the client cannot be reached or an incorrect answer is given, the switch port is then closed.
Since this is the first draft of this idea, several flaws exist in this system. I will attempt to address them all:
Although this is a very possible situation, this should be a bit diffcult. Each node has a different key file set for SERVER->CLIENT communications. This system should prevent rouge nodes from poping up as SWAP servers.
This is a major problem. A rouge node can "learn" a key file over time if the key space is exhausted durring the sniffing section. This can be partially prevented by using large keys and randomized offsets. However, a seperate encryption layer may be needed when the key data is sent over the air. This key would have to be cracked in order to start "learning" a key file. This can prove very diffcult.
This problem is a bit more difficult to solve. Rouge node can assume the MAC address of a trusted node and start generation of packets. These would be dropped by the trusted node and may result in errors, but picked up by the rouge node. The rouge node could ignore challenges and let the trusted node respond. The only solution I can think of is using a challenge each time the trusted node issues a connection. If the node did not orginate the connection, it would be dropped. Mangling of the IP header options can also be done by throwing an authentication string in each first connection packet. I have no easy solution for this problem.
There are a couple of more issues which I cannot remember anymore. I will post these later. Feel free to submit an idea.
Casey Halverson
Copyright 2001
Commando@wolfenet.com