Talking about authentication a number of related terms like (digital) identity, authorization, privacy etc. pop up. So before we get into authentication proper we need to introduce some terminology, without trying to be exhaustive.
Digital identity is the electronic entity that is a representation of a physical entity, like a person or a device. Authentication is the process of verifying the claim that an (electronic) entity is allowed to act on behalf of a given known (physical) entity. In other words, authentication is the process of proving that the physical entity corresponds to a certain electronic one. Authorization in turn is the process of establishing the rights of the identity to access certain resources or to perform certain tasks. Privacy, finally, is a complex issue but has to do with the right of a person not to have their personal data and behaviour be known to parties that do not strictly need that to provide the service the users request. So for example, it is reasonable for a liquor shop to know that a customer is above a certain age before selling alocholic drinks, but to know the name of the customer, third parties should not have knowledge of the transaction at all. Privacy is of particular concern in a world in which users increasingly use networks and services outside their home environment. Without proper attention to privacy aspects it is too easy to trace a users behaviour and movement. It is worth mentioning that there is a tension between authentication and privacy. Verifying the identity of a user in itself invades the user's privacy, the authenticating party knows who is using what a resource at a particular time and location, but the challenge is to minimize the amount of information about a user and the number of parties that are privvy to that information.
In the context of this book we are mainly interested in techniques for controlling access to the network. In other words, we want to be able to decide who (authenticated identity) gets to access what (authorization). Authentication is typically done by prove of knowledge of a secret (a password, a signature), possession of a token or characteristic (a certificate, a fingerprint) or both. Access control is often needed to make sure that only authorized users can use the network, to prevent exhaustion of scarce resources and/or complieance with rules and regulations. In addition to access controlled networks there may also be open networks with limited access or for a limited time, but due to the need for organizations to control access to their scarce resources and also anti-terrorist laws they become less ubiquitous.
Over the years a number of techniques have been employed to controll access to the wireless network. Susequently they have been mostly abandoned due to security or scalability issues as WiFi became increasingly popular.
Access to a WiFi network can be based on the MAC address. This is the 48-bit number assigned by the manufacturer to every wireless and Ethernet device, that is supposed to be unique and persistent. By employing mac filtering on our access points, we can authenticate users based on their MAC address. With this feature, the access point keeps an internal table of approved MAC addresses. When a wireless user tries to associate to the access point, the MAC address of the client must be on the approved list, or the association will be denied. Alternately, the AP may keep a table of known “bad” MAC addresses, and permit all devices that are not on the list. Unfortunately, this is not an ideal security mechanism. Maintaining MAC tables on every device can be cumbersome, requiring all client devices to have their MAC addresses recorded and uploaded to the APs. Even worse, MAC addresses can often be changed in software. By observing MAC addresses in use on a wireless network, a determined attacker can spoof (impersonate) an approved MAC address and successfully associate to the AP. While MAC filtering will prevent unintentional users and even most curious individuals from accessing the network, MAC filtering alone cannot prevent attacks from determined attackers. MAC filters are useful for temporarily limiting access from misbehaving clients. For example, if a laptop has a virus that sends large amounts of spam or other traffic, its MAC address can be added to the filter table to stop the traffic immediately. This will buy you time to track down the user and fix the problem.
Another at one time popular "authentication feature" of WiFi network is the so-called closed network mode. In a typical network, APs will broadcast their ESSID many times per second, allowing wireless clients (as well as tools such as NetStumbler) to find the network and display its presence to the user. In a closed network, the AP does not beacon the ESSID, and users must know the full name of the network before the AP will allow association. This prevents casual users from discovering the network and selecting it in their wireless client. There are a number of drawbacks to this feature. Forcing users to type in the full ESSID before connecting to the network is error prone and often leads to support calls and complaints. Since the network isn’t obviously present in site survey tools like NetStumbler, this can prevent your networks from showing up on war driving maps. But it also means that other network builders cannot easily find your network either, and specifically won’t know that you are already using a given channel. A conscientious neighbor may perform a site survey, see no nearby networks, and install their own network on the same channel you are using. This will cause interference problems for both you and your neighbor. Finally, using closed networks ultimately adds little to your overall network security. By using passive monitoring tools (such as Kismet), a malicious user can detect frames sent from your legitimate clients to the AP. These frames necessarily contain the network name. The malicious user can then use this name to associate to the access point, just like a normal user would.
Encryption is probably the best tool we have for authenticating wireless users. Through strong encryption, we can uniquely identify a user in a manner that is very difficult to spoof, and use that identity to determine further network access. Encryption also has the benefit of adding a layer of privacy by preventing eavesdroppers from easily watching network traffic. Encryption is the technique that is used for authenticating users in most current deployments.
The first widely employed encryption method on WiFi networks was WEP encryption. WEP stands for wired equivalent privacy, and is supported by virtually all 802.11a/b/g equipment. Incidentally, this is a complete misnomer as the privacy that WEP provides is in no way equivalent to that of wired connections. WEP uses a shared 40-bit key to encrypt data between the access point and client. The key must be entered on the APs as well as on each of the clients. With WEP enabled, wireless clients cannot associate with the AP until they use the correct key. An eavesdropper listening to a WEP-enabled network will still see traffic and MAC addresses, but the data payload of each packet is encrypted. This provided an authentication mechanism while also adding a bit of privacy to the network. WEP is definitely not the strongest encryption solution available. For one thing, the WEP key is shared between all users. If the key is compromised (say, if one user tells a friend what the password is, or if an employee is let go) then changing the password can be prohibitively difficult, since all APs and client devices need to be changed. This also means that legitimate users of the network can still eavesdrop on each others’ traffic, since they all know the shared key. The key itself is often poorly chosen, making offline cracking attempts feasible. But most importantly, WEP itself is broken, making it relatively easy to crack the network.
For more details about the state of WEP encryption, see these papers:
http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
http://www.cs.umd.edu/~waa/wireless.pdf http://www.crypto.com/papers/others/rc4_ksaproc.ps
Another data-link layer authentication protocol is Wi-Fi Protected Access, or WPA. WPA was created specifically to deal with the known problems with WEP mentioned earlier. WPA was intended to be a backwards compatible interim solution while the full standard 802.11i (WPA2) was developed. WPA and WPA2 can operate in combination with the 802.1X umbrella standard for wireless authentication (see below) but also much in the same mode as WEP, with a shared secret between all clients and the AP, the so-called Pre Shared Key (PSK) mode (the WiFi Alliance calls WPA-PSK "WPA Personal", as opposed to "WPA Enterprise" that is used in combination with 802.1X). Overall, WPA provides significantly better authentication and privacy than standard WEP, mainly by leveraging the Temporary Key Integrity Protocol (TKIP) that continuously and automatically changes the keying material between clients and access points.
Unfortunately precisely the backwards compatibility of TKIP has given rise to some attack vectors against TKIP that allow for decrypting certain encrypted packets, that in term can be manipulated for further attacks.
More information can be found in the following articles:
http://dl.aircrack-ng.org/breakingwepandwpa.pdf http://download.aircrack-ng.org/wiki-files/doc/enhanced_tkip_michael.pdf
Consequence of these discoveries is that is wise to move to the next generation of secure WiFi acces protocols: WPA2
WPA2 is the full IEEE 802.11i standard. The main difference with WPA is the use of in addition to TKIP the Advanced Encryption System (AES), a (so far) not broken encryption standard. So the use of WPA2 with AES can be considered secure.
It should be noted that whereas WEP, WPA-PSK and WPA2-PSK are using encryption techniques to provide access control and protect against eavesdropping, they only protect the traffic between client and access point. In order to protect the communication against unauthorized tampering or eavesropping end to end encryption is needed, using techniques like the ones described in the security chapter.
The major downside of any of these latter three authentication methods is that, regardless of the strength of the encryption, they are built upon the notion of a common shared secret between client an access point. They don't allow for identifying individual users and frankly, a secret shared by potentially tens of thousands of users can hardly be called a secret. The concerns about security, acountability and scalability have led to the rise of what is commonly called identity-based networking.
In identity based networking individual users are being authenticated rather than secrets shared between many users. Typically the authentication system verifies user credentials against some sort of enterprise database or directory. Commonly by using the RADIUS protocol, a protocol originally designed for controlling access to dial-in modem pools but sufficiently versatile to serve as generic access control protocol for network access.
One common authentication tool used on wireless networks is the captive portal. A captive portal uses a standard web browser to give a wireless user the opportunity to present login credentials. It can also be used to present information (such as an Acceptable Use Policy) to the user before granting further access. By using a web browser instead of a custom program for authentication, captive portals work with virtually all laptops and operating systems. Captive portals are typically used on open networks with no other authentication methods (such as WEP or MAC filters). To begin, a wireless user opens their laptop and selects the network. Their computer requests a DHCP lease, which is granted. They then use their web browser to go to any site on the Internet.  Figure 6.1: The user requests a web page and is redirected.
Instead of receiving the requested page, the user is presented with a login screen. This page can require the user to enter a user name and password, simply click a “login” button, type in numbers from a pre-paid ticket, or enter any other credentials that the network administrators require. The user then enters their credentials, which are checked by the access point or another server on the network. All other network access is blocked until these credentials are verified.  Figure 6.2: The user’s credentials are verified before further network access is granted. The authentication server can be the access point itself, another machine on the local network, or a server anywhere on the Internet.
Once authenticated, the user is permitted to access network resources, and is typically redirected to the site they originally requested.  Figure 6.3: After authenticating, the user is permitted to access the rest of the network.
Captive portals provide no encryption for the wireless users, instead relying on the MAC and IP address of the client as a unique identifier. Since this is not necessarily very secure, many implementations will require the user to re-authenticate periodically. This can often be automatically done by minimizing a special pop-up browser window when the user first logs in. Since they do not provide strong encryption, captive portals are not a very good choice for networks that need to be locked down to only allow access from trusted users. They are much more suited to cafes, hotels, and other public access locations where casual network users are expected. Another downside of captive portals is that they rely on the use of a browser for authentication, which can be very counterintuitive for users that just try to check their e-mail or send an instant message, not to mention the fact that many wireless devices like sensors, printers and cameras don't have a builtin browser.
In public or semi-public network settings, encryption techniques such as WEP and WPA are effectively useless. There is simply no way to distribute public or shared keys to members of the general public without compromising the security of those keys. In these settings, a simple application such as a captive portal provides a level of service somewhere between completely open and completely closed.
Many vendors and open source projects exist that provie captive portal capability, to name a few:
CoovaChilli, CoovaAP (http://.....)
Coova is the succesor of the no longer actively maintianed Chillispot project. Coova allows for the use of a RADIUS authentication backend.
WiFidog (http://www.wifidog.org/)
WiFi Dog provides a very complete captive portal authentication package in very little space (typically under 30kb). From a user’s perspective, it requires no pop-up or javascript support, allowing it to work on a wider variety of wireless devices.
M0n0wall, pfSense (http://m0n0.ch/wall/).
m0n0wall is a complete embedded operating system based on FreeBSD. It includes a captive portal with RADIUS support, as well as a PHP web server.
Many general networking vendors offer some form of integrated captive portals, e.g. Microtik, Cisco, Aruba, Aptilo.
In enterprise and campus deployments, the most common wireless network authentication framework is that based on IEEE 802.1X. 802.1X is a layer 2 protocol that can be used both for wired and wireless network authentication and in fact comprises a number of technologies. 802.1X describes the interaction between the client device (supplicant in 802.1X) and the Access Point or Switch (Authenticator) as well as that between the Access Point or Switch and a backend RADIUS server (Authentication Server) that in turn verifies user credentials against an enterprise directory or flat file for that matter. Finally, 802.1X describes how to transport user credentials from the supplicant to the authentication server transparently to the authenticator or any other device in the path by leveraging the Extensible Authentication Protocol (EAP).
The encryption between the supplicant and the authenticator can be done using rotating WEP-keys, WPA with TKIP or WPA2 with AES. For the reasons mentioned in the paragraph on WEP, WPA-PSK and WPA2-PSK, WPA2 with AES is highly recommended.
Probably the most interesting feature of the 802.1X is the use of EAP. EAP defines a generic way of encapsulating credentials and transport them from a supplicant (client software) to an authentication server (RADIUS server). So-called EAP-methods define how specific authentication methods can be encapsulated into EAP. There exist EAP-methods for all common types of authentication methods like certificates, SIM-cards, username/password, one-time passwords and hardware tokens. Due to key or token distribution problems with handing out tokens or certificates and revocation the vast majority of large scale deployments use what are called tunneled EAP-methods: username/password based authentication using a TLS tunnel to the authentication server through which the actual username and password are transmitted. The user identity used for the TLS-envelope is typically of the form anonymous@domain (this is called the outer identity) whereas the inner identity (inside the TLS tunnel) is of the form username@domain. This distinction is particularly interesting for roaming to other organizations network purposes. It is possible to transport the authentication credentials of a user over the Internet while only revealing the home organization of the user (the domain part), but that is the topic of the next paragraph.
So what happens in a typical 802.1X authentication with a tunneled EAP-method is the following:
There are a number of tunneled EAP-methods that essentially work the same, the differences are in the support in common operating systems, the vulnarability to dictionary and man-in-the-middle attacks and whether they require storage of clear-text passwords in the backend.
The most widely deployed tunneled EAP-methods nowadays are EAP-TTLS (EAP Tunneled Transport Layer Security) and PEAP (Protected EAP). There have been incompatible implementations of PEAP due to disagrements between the proponents of PEAP (Apple, Cisco and Microsoft) resulting in a large uptake of TTLS. The fact that these incompativilities are largely solved and the lack of native support for TTLS in a number of common OSes (Apple iOS and MS Windows variants) have resulted in an increase in uptake of PEAP. A newer EAP-method that is gaining traction is EAP-FAST due to its security properties, and EAP-FAST has also been chosen as the basis for the new to be developed tunneled EAP-method that the IETF expects to be the single endorsed one.
RADIUS has the interesting property that RADIUS messages can be proxied to other RADIUS-servers. That means that it is possible for organization to allow for eachothers users to gain access to the network by authenticating to their home oranizations RADIUS server. When the RADIUS-server of organization A receives an authentication requests from anonymous@organizationB.org it can forward the request to the organization B RADIUS-server instead of verufying the credentials locally. Organization B's RADIUS server in turn can verify the credentials and send the access accept back to the organization A RADIUS server, that then tells the Access Point to allow the user access. This so-called federated access allows for the creation of very scalable and large deployments while at the same time allowing the individual organizations to apply there own authentication policies to their users. While RADIUS proxying is certainly possible in captive portal deployments it definately shines in an 802.1X/EAP environment. By using EAP the user credentials can be protected so that only the home organization of the user is able to see them. This way large deployments can be created without the leakage of credentials and without teaching users to enter their secret credentials in every website that is thrown up in fromt of them. As an example, eduroam, the roaming wireless access federation in education, that extents the above concept slightly by instead of having direct RADIUS connections between organization builds a hierarchical system of national and internation RADIUS servers, allows 100s of thousands of students to gain access to campus networks in many countries in all continents with the exception of Antarctica.
pic: http://en.wikipedia.org/wiki/File:802.1X_wired_protocols.png
There has been error in communication with booki server. Not sure right now where is the problem.
You should refresh this page.
