1. Introduction
Overview
Wireless (WiFi) is emerging as a significant aspect of networking. It presents a set of unique issues based on the fact that the only limit to a wireless network is the radio signal strength. There is no wiring to define membership in a network. There is no physical method to restrict a system in radio range to be a member of a wireless network. Wireless networking, more than any other networking technology, needs an authentication and access control mechanism to ensure security.
The IEEE 802.11 group has defined standards for WiFi including both radio standards and networking protocol standards. The intent of these standards is to provide a wireless Ethernet capability. The 802.11 standard has specified the use of 802.1x RADIUS Server authentication mechanisms for authenticating user access to the LAN. This paper looks at 802.11 security issues, the existing and proposed technologies, and scenarios for use.
IEEE 802.11 is the wireless LAN Standard. The original 802.11 standard included support for “Wired Equivalent Privacy” to protect messages going over the air. WEP requires a shared key to protect messages, and the original standard assumed that these keys would be configured in the devices. Later versions of the standard have added the use of 802.1x RADIUS Server for authenticating users and a mechanism for creating “dynamic” session keys. Currently, work in the IEEE is addressing several areas having to do with access authentication for 802.11 wireless networks. This paper focuses on two areas of the standards.
- Device (STA) authentication via 802.1x and remote RADIUS server. This leverages off of work done in the IETF, most notably the RADIUS server and its Extensible Authentication Protocol (EAP). Work on EAP and 802.1x RADIUS is being done in the EAP working group of IETF and the 802.1 task group of IEEE to deal with issues raised by deployment of 802.11 LANs.
- Per-packet authentication (message integrity) and encryption technology. This is to replace Wired Equivalent Privacy (WEP). The initial WEP algorithm has been shone to be relatively easy to break.
The revised WLAN standards, properly deployed, will make authenticated wireless networking a safe computing environment.
This paper describes the current state of access control with existing 802.11 devices, our understanding of the ways the standards will change, and highlights some of the issues that are in the process of being resolved. The paper also describes how we expect wireless services to evolve with the revised standard.
- Section 2 describes the basic wireless infrastructure and defines terms.
- Section 3 covers risks associated with current wireless LAN services.
- Section 4 describes the access control tools used with wireless LANs today.
- Section 5 covers 802.1x-based RADIUS server authentication.
- Section 6 is about problems being addressed by standards bodies and their likely fixes.
- Section 7 summarizes and draws conclusions.
The paper was written to be read sequentially but someone with good knowledge of wireless may pick and choose from the separate sections.
This paper concentrates on authentication services for 802.11 (WLAN) in what is referred to as Infrastructure mode. In this mode all wireless station communication is passed through an access point whose function is similar to that of a wired hub. This paper will also cover privacy and integrity services triggered by the authentication services and how the authentication services themselves benefit from these privacy services.
Figure 1. Wireless LAN access terminology.
- AP Access Point. An 802.11 hub/bridge that provides star topology control on the wireless side and access to a wired network.
- AS Authentication Server. An 802.1x component for performing authentication services for devices requesting admittance to a network. Implementations include a RADIUS server or other AAA servers.
- STA Wireless Station. Any 802.11 device other than an access point.
An infrastructure network has security /integrity requirements. 802.11-1999 only defined a single security option, WEP. Efforts with the IEEE 802.11 workgroup and the vendor WiFiI Alliance are producing security architecture alternatives.
Wired Equivalent Privacy
WEP was designed to provide:
- Reasonable Strength: The security afforded by the algorithm relies on the difficulty of discovering the secret key through a brute-force attack.
- Self-synchronization: WEP is self-synchronizing for each message. This property is critical for a data-link level encryption algorithm, where “best effort” delivery is assumed and packet loss rates may be high.
- Processing efficiency: The WEP algorithm is efficient and may be implemented in either hardware or software.
- Exportability: Every effort was made to design the WEP system operation so as to maximize the chances of approval, by the U.S. Department of Commerce, of export from the U.S. of products containing a WEP implementation. However, due to the legal and political climate toward cryptography at the time of publication, no guarantee can be made that any specific IEEE 802.11 implementations that use WEP will be exportable from the USA.
These design goals for WEP were established to match the security of a wired network. Since the time of its design, 1995, WEP has been found to be easily broken.
Wi-Fi Protected Access
Wi-Fi Protected Access is an alternative supported by the Wi-Fi Alliance, the 802.11 vendor forum. WPA is NOT an IEEE standard, but is derived from an IEEE draft document. WPA works for Infrastructure mode and includes the following:
- Authentication mechanisms for both APs and STAs based on 802.1x
- Key management algorithms
- Dynamic, association-specific cryptographic keys
- Enhanced data encapsulation mechanism, using TKIP
WPA certification was made available to vendors from the Wi-Fi Alliance in the spring of 2003, and made mandatory in the fall of 2003.
Before discussing access control protocols, one should understand the threats to wireless LAN security.
The nature of an RF based network leaves it open to packet interception by any radio within range of a transmitter. Interception can occur far outside the users’ normal ‘working’ range by using hi-gain antennas. With readily available tools, the eavesdropper is not limited to just collecting packets for later analysis, but can also catch weak authentication exchanges, like some website logins.
Encrypting data between the STA and AP can mitigate eavesdropping of user data. However, the ability to sniff also makes attacks on encryption easier, and mandates requirements for strong encryption algorithms.
Once an attacker has gained the knowledge of how a WLAN controls admittance, he may be able to either gain admittance to the network on his own, or steal a valid STA’s access. Stealing a STA’s access is simple if the attacker can mimic the valid STA’s MAC address and use its assigned IP address. The attacker waits until the valid system stops using the network and then takes over its position in the network.
This would allow an attacker direct access to all devices within a network, or to use the network to gain access to the wider Internet, all the while appearing to be a valid user of the attacked network.
To mitigate this danger the AP and STA need to support “message integrity”. This means signing every message using a shared key.
An attacking STA can poison the ARP tables in switches on the wired network through the AP causing packets for a wired station to be routed to the attacking STA. The attacker can either passively capture these packets before forwarding them to the attacked wired system, or attempt a man-in-the-middle attack. In such an attack, all the susceptible systems could be on the wired network
Link-layer authentication stops an outsider from perpetrating this attack. Network-layer (e.g. IPsec) stops an insider from perpetrating this attack.
Denial of service attacks against a WLAN can range from simple radio interference (a 2.4Ghz cordless phone is an example of such an attacking device) to more subtle attacks against a single STA or AP. An attacking system could replay a captured 802.11 disassociate message, or an 802.1x EAPOL-logoff message, and effectively disconnect a STA from the WLAN.
It is considered impossible to build a network without some DOS attacks, thus the thrust is to minimize them and to be able to recognize and trace them back to their source.
An 802.11 wireless network is very susceptible to a rogue AP attack. A rogue AP is one owned by an attacker that accepts STA connections and then at a minimum intercepts traffic if not also performing man-in-the-middle attacks before allowing traffic to flow to the proper network. The goal of a rogue is pulling valid traffic from the WLAN to a wired network for attacking (or to conduct the attack directly within the rogue AP) and then reinserting the traffic into the proper network.
A newer form of a rogue AP is a STA with two wireless cards. With one, it acts as a valid station to the ESS, with the other it acts as an AP to other STAs. Such rogue APs could readily be deployed in public areas as well as shared office space areas.
Each wireless network has an SSID that it uses to identify the APs that are a part of the wireless network. A common way of configuring a network is to require each STA to know the SSID of the AP to which it wants to connect. By default, all APs broadcast their SSID as an advertisement of their presence.
A SSID provides a very modest amount of control. It keeps a STA from accidentally connecting to a neighboring AP. It does not, by itself, help with other security issues, and in particular it does not keep an attacker from accessing the ESS or from setting up a “rogue” AP that uses the same SSID as a valid AP.
It is possible to turn off SSID broadcasts. This does make WLAN discovery by an attacker harder, but when a station PROBES for an AP SSID, the AP responses with a one-time broadcast, so the patient attacker will still discover SSIDs. SSID hiding is impossible, and is not a security measure.
Some APs provide the capability for checking the MAC address of the STA before allowing it to connect to the network. This provides an additional layer of control in that only STAs with a registered MAC address can connect. A list of MAC addresses may be kept in long-term memory on the AP, or the AP may send the MAC address to a central RADIUS server for authentication. The RADIUS server approach is especially appropriate if the MAC addresses are to be used with multiple APs.
Using MAC filters is considered to be very weak security because on many wireless cards it is possible to change the MAC address by reconfiguring the card. An attacker could sniff a valid MAC address from the wireless network traffic and then configure his card to use it and gain access.
Wired Equivalent Privacy (WEP) is part of the 802.11 specification. Static WEP key operation requires keys on the STA and AP that are used to encrypt data sent between them. With WEP encryption, sniffing is eliminated and session hijacking is difficult (or impossible). STA and AP are configured with a set of 4 keys, and when decrypting each are used in turn until decryption is successful. This allows keys to be changed dynamically.
As described above, keys are the same in all STAs and APs. This means that there is a “community” key shared by everyone in the wireless network. The danger is that if any one in the community is compromised, the community key, and hence the network and everyone else using it, is at risk.
As it turns out, the current version of WEP encryption has been proven to be very vulnerable. WEP is not strong protection.
There are a number of methods for dynamically setting the WEP keys. The most commonly used now is 802.1x. Kerberos is also used.
Many people use VPNs to protect their connection over a wireless network. This is not strictly a wireless solution—it can be used in any remote access situation. VPNs can provide integrity checking and, optionally, encryption of sessions. VPNs only protect the STA traffic routed through the VPN, not the STAs or the network. Without support for Link layer integrity such as 802.1X with a RADIUS server, the connection between the STA and the AP is vulnerable to unsophisticated, easy to mount, denial of service attacks. In addition, the STA and Client are vulnerable to direct attacks. Adding a personal firewall product at a financial and management cost can mitigate the Client risk.
Deploying a firewall between the AP and the network that only allows authenticated VPNs access can provide network protection against attacks, but at a price. The firewall will require each workstation to establish a separate tunnel to the firewall. Authentication of the tunnel is required, and will be managed after the network connection is established, requiring different support in either the client or the AP. A VPN gateway CAN provide this level of protection directly. However, if the user needs to establish an additional tunnel, to a remote corporate firewall for instance, this will require a tunnel over a tunnel, which is expensive in cpu cycles on the STA and for most VPN clients has not been heavily tested.
In most current situations, using a VPN with a single firewall is a good idea whether dialing in from a remote location or connecting via a wireless Access Point. Adding Link layer encryption to the wireless session solves the wireless specific issues.
Several vendors have implemented nonstandard solutions that provide additional security.
- Cisco LEAP is an 802.1x-based solution (see below) that uses a proprietary algorithm to support mutual authentication between a STA and a RADIUS server. The RADIUS server, Client, and AP must all support the LEAP algorithm for this to work.
- Agere provides a solution that uses a non-standard dialog between the STA and the AP to allow standard PPP authentication methods to be used. This allows any standard RADIUS server to be used to authenticate a user.
- Symbol Technologies supports a service where client, access point and AS are based on Kerberos.
- 3COM provides a way to create a PPTP tunnel and uses a standard RADIUS server to authenticate the tunnel.
The open nature of WLAN requires authentication of the STAs to the APs. There are no wires to follow to determine which STAs are part of the network. An authentication process will allow an AP to restrict which STAs can associate with it. However, session authentication by itself, as will be shown, is inadequate for WLAN. WEP lacks message integrity, an essential component in security.
Per-packet message integrity checking (sometimes called per packet authentication) is the only way for an AP to determine that a packet was sent from an authenticated STA and for the STA to determine that a packet came from the authenticating AP. All message integrity algorithms need a key that is shared by the two systems. This, in turn, requires that the STA session authentication process must end with a session key shared by the two systems.
A further analysis of the risks inherent in WLAN places one more stipulation on any WLAN authentication process. Since the STA has no method short of authenticating the AP to trust the AP it associates with, the authentication process must provide explicit authentication of the AP or network.
802.11 WLAN is now specifying the use of IEEE 802.1x (Port-Based Network Access Control) to provide the station authentication. 802.1x is an authentication dialog between the system needing network services and the network. This dialog uses the IETF Extensible Authentication Protocol (EAP). 802.1x consists of a Port Access Entity (PAE) in all STAs and APs, EAP encapsulation over LANs (EAPOL), and a RADIUS Server as an Authentication Server (AS).
802.1x redefines our traditional understanding of a network interface and adds access authentication services to it. In 802.1x the principal component is the Network Access Port (or just Port) that can either be a physical network interface or a virtual MAC. Above the Port is the Port Access Entity (PAE); the controlling logic that manages which device’s packets will be accepted by another device.
Figure 2. 802.1x Port Based Network Access Control
There are two types of systems supporting ports and PAEs: supplicants and authenticators (see figure 2.). In WLAN infrastructure usage, STAs are supplicants and APs are the authenticators. In all systems there are two types of Ports: Controlled and Uncontrolled ports. A Controlled port will only accept packets from authenticated systems. That is a packet whose MAC address is on the list of authenticated addresses, whereas an Uncontrolled port will accept any packet. Normally the Uncontrolled port will only use packets to establish authentication; in 802.1x these are EAPOL packets (EAP over LAN and EAPOL key).
This aspect of authentication to a MAC address is fundamental to 802.1x. The authenticator has no other way to identify the supplicant or its packets without a high-layer per-packet authentication mechanism.
The third component is the authentication server (AS) that typically takes the form of a RADIUS server. The main function of the authenticator system is to act as an EAP proxy between the supplicant and the RADIUS server (AS). That is, it accepts EAPOL EAP packets from the supplicant and forwards the EAP packets to the RADIUS server (AS) over a protocol like the RADIUS protocol. It also forwards all RADIUS server (AS) EAP packets over EAPOL to the supplicant. In this manner, the supplicant is authenticated to the network. Once this is done, the RADIUS server (AS) provides the authentication state of the supplicant to the authenticator system via the secure RADIUS channel between the two.
The standard for access authorization between a STA and an AP is 802.1x. The de facto standard for communication between the AP and the RADIUS server (AS) is RADIUS.
The authentication dialog between the STA and the AS is carried in EAP frames. The EAP frames are carried as EAPOL (EAP over LAN) in 802.1x, and as EAP Message attributes in RADIUS.
The standard authorization dialog consists of:
Figure 3. 802.1x authorization dialog.
- AP requests an identity from STA using EAPOL.
- STA sends its identity to the AP.
- AP forwards the STA identity to RADIUS server (AS) via EAP.
- The RADIUS server (AS) and STA have an EAP authentication dialog (see next section for types of dialog).
If Dialog is successful, STA and RADIUS server (AS) share a session key.
- RADIUS server (AS) sends the session key to the AP in a RADIUS Attribute as part of the RADIUS Access-Accept message.
- AP enables its controlled port for the STA’s MAC address and optionally enables a key via the EAPOL-Key packet.
The authentication dialog between the STA and RADIUS server (AS) must be negotiated between them as part of the EAP dialog. Several EAP authentication methods have been standardized for use with PPP, but good practice for 802.11 requires mutual authentication and the creation of a shared session key as part of the authentication method. In other words, wireless authentication should be explicit mutual authentication: both parties have cryptographic evidence of the other’s identity.
EAP-TLS and PEAP are available in Microsoft XP. Other EAP methods require the installation of supplicant software in the STA.
EAP-TLS
EAP-TLS authentication is based on X.509 certificates. In WLAN usage, the STA must have a certificate that the RADIUS server (AS) can validate. Likewise, the RADIUS server (AS) will present a certificate to the STA and the STA will have to validate it.
- It is resilient to man-in-the-middle attacks. We do not really care if an attacker is intercepting the exchange. Properly implemented, EAP-TLS resists such attacks.
- It provides explicit mutual authentication between the RADIUS server (AS) and the supplicant. This is only true if both parties can validate the other’s certificate. This is typically done by having both certificates issued by one CA, and for each party to have the CA’s certificate and CRL to validate the certificates.
- After the exchange, there is a shared session secret between the RADIUS server (AS) and the supplicant. Once the RADIUS server (AS) supplies this to the authenticator system via their secure link, the authenticator system and the supplicant can use it to bootstrap their per-packet authenticated, secure communication.
EAP-TLS requires the complexity of a PKI to support STA authentication. This may be acceptable in large corporate deployments, but is likely to be burdensome for SOHO and small and medium enterprise deployments. A strong password authentication method with User ID and Password is a more practical authentication for many public deployments.
Protected EAP methods
To mitigate the complexity and cost of deploying the user certificates required to support EAP-TLS, two methods have been developed that use a server side certificate to allow authentication of the server and creation of an EAP-TLS tunnel that then carries other authentication methods through the tunnel. The two methods that have been proposed are EAP-PEAP (Protected EAP) and EAP-TTLS (Tunneled TLS).
Protected EAP methods tend to take many round trips to complete. This can be mitigated in part by using the resume feature of TLS.
Recently a Man-in-the-Middle attack has been described which can be mounted against these methods in certain circumstances.
PEAP
PEAP (Protected EAP) extends the TLS challenge to carry an EAP exchange. Once the initial TLS exchange is complete which authenticates the server to the user, any other EAP method can be used to authenticate the user to the server. Thus traditional EAP methods like MD5 or MSCHAP can be used in conjunction with PEAP. Some PEAP characteristics:
- Two EAP exchanges, 1st to set up TLS, second to use TLS for protection
- Provides Certificate-based RADIUS server (AS) authentication by using standard TLS methodology.
- Authenticates the STA’s RADIUS server (AS) to the STA.
- STA authentication using any EAP type within EAP-TLS tunnel.
- STA Identity hiding by using generic Identity in outer EAP and real Identity within TLS
- Fast reconnect using TLS session resume.
PEAP avoids much, but not all of the PKI complexity of TLS. AS’s must have Certs and STAs MUST be configured with the root cert of the RADIUS server (AS) to validate the RADIUS server (AS) name within the RADIUS server (AS) certificate in order to avoid the SSL man-in-the-middle attack from Rogue APs. STAs MUST also use some form of certificate validation to be sure the AS certificate has not been revoked. For example: CRLs or OCSP are both protocols for checking Certificate Revocation.
In Windows XP clients, the user interface for PEAP is EAP, as PEAP presents EAP to XP.
“Inner” EAP Success and Failure messages are protected within TLS tunnel, EAP-failure is clear text if “outer” EAP-TLS fails. This is different than TTLS (see below) where all EAP Success and Failure messages are in the clear.
EAP-TTLS
EAP-TTLS (EAP Tunneled TLS Authentication Protocol) uses TLS to provide a secure channel for traditional PPP authentication methods like CHAP, MS-CHAP, MS-CHAP-V2, and EAP/MD5- Challenge. This can reduce the certificate requirements (as with PEAP only the AS needs one) and leverage legacy RADIUS authentication methods (PAP and CHAP). This is perhaps the most appealing feature of TTLS - the ability to continue using existing “legacy” RADIUS servers to authenticate wireless LANs, by inserting a RADIUS/EAP-TTLS Server between the Wireless APs and the legacy RADIUS server. Some characteristics of TTLS:
- Provides Certificate-based RADIUS server (AS) authentication by using standard TLS methodology.
- Authenticates the AP’s RADIUS server (AS) to the STA. As opposed to TLS that only authenticates the STA’s RADIUS server (AS) to the STA.
- STA authentication using ‘weak’ standard PPP methods as well as any EAP type within PPP.
- STA Identity hiding by using generic Identity in outer EAP and real Identity within EAP-TLS tunnel
TTLS avoids much, but not all of the PKI complexity of TLS. The RADIUS server (AS) must have Certs and STAs MUST be configured with the root cert of the RADIUS server (AS) to validate the RADIUS server (AS) name within the RADIUS server (AS) certificate in order to avoid the SSL man-in-the-middle attack from Rogue APs. STAs MUST also use some form of certificate validation to be sure the RADIUS server (AS) certificate has not been revoked. For example: CRLs or OCSP are both protocols for checking Certificate Revocation.
Future Authentication Types
A number of authentication types have been mentioned as possible methods for Wireless LANS. Some of these are listed below and others will likely emerge. This is the area where the future is the cloudiest. It is not clear whether one or more of these authentication methods will become the defacto standard or if there will be different authentication methods used by different applications, NIC cards, and authentication vendors.
EAP-SIM
SIM cards are used by Mobile devices to authenticate to Cellular networks. A SIM card holds a secret known only to a central registry. An EAP-SIM method has been proposed to allow the SIM card and its information to be used to authenticate users accessing the network.Smart/challenge cards
Vendor specific methods will likely be implemented to support mutual authentication and work with EAP. In these cases the user may authenticate with the vendor specific method and the network (RADIUS server or AAA server) may authenticate itself with another method.
Kerberos
Kerberos can be used for mutual authentication and key generation. A problem to be overcome with Kerberos implementations is that many Kerberos implementations require an IP address for the requestor, and in this mode the IP address is often assigned after authentication rather than before.
Other EAP Methods
The Internet Draft Directory also contains documentation for the AKA EAP method.
The 802.11 and other standards groups are working on a number of issues. Most of these have been mentioned explicitly or implicitly above. Some of the issues are spelled out in more detail in this section.
WEP provides encryption of packets, but not message integrity. Proposals for AES, TKIP, and WPA all support message integrity. Not providing Message Integrity allows the following bad things:
- 802.11 does not provide cryptographic integrity checking of each message. It trusts the MAC address provided by the STA. Since there is no per-packet cryptographic integrity check tied to the authentication key an attacker can spoof the authenticated STA. The attacker can simply note the MAC and IP addresses used, and after the valid STA leaves, start using these values to send packets.
- A valid STA in the wireless network can pose as an AP (typically takes two 802.11 interfaces in the system). Other STA closer to this rogue than a valid AP will associate with the rogue. The rogue could simply send a EAP-Success and start accepting traffic from the mis-directed STA.
- The absence of integrity checking can also be used as a Denial Of Service attack against a STA by sending WLAN MAC sublayer management frames like the DISASSOCIATE frame.
- An attacker can readily replace the packet content if it is unencrypted. Even if the packet is encrypted, portions can be replaced in such a manner as to appear as valid frames after decrypting to 802.11, but to be invalid to the application.
With the authentication method described above, the STA never authenticates to the AP, only the RADIUS server (AS). In many deployments, the static authentication (via a shared secret) between the AP and the RADIUS server (AS) provides adequate transitive trust. In a complex deployment with chained RADIUS servers, however, the STA never knows the network it authenticated to, as the SSID has no trust relation with the STA.
Some thought is being given to adding an option to the access sequence where the STA and AP authenticate each other based on information passed to the STA by the RADIUS server in the access authentication (EAP) dialog.
RADIUS supports a static secret key between the authenticator (AP) and the RADIUS server (AS). These secrets are rarely, if ever, changed. This presents an opportunity for an attacker that, through social engineering, learns the key and can intercept the encrypted traffic between the APs and AS or even impose a rogue AP into the network. This attack is being evaluated. RADIUS proxies with this mechanism have been deployed to support remote dial access in many places without problems (at least known by the authors) with this sort of attack. Wireless, however, will be a more visible environment and may draw more attention than previous wired deployments. Methods of supporting key updating for RADIUS have been discussed.
STA and AP authentication is just the first step in access control for WLAN. Each packet on a wireless network may need to be authenticated and optionally encrypted for privacy. Currently WEP provides only packet encryption.
In December 2000, a series of theoretical attacks against WEP were published. In July 2001, code for a simple passive attack against WEP was published on the Internet. A replacement for WEP was well underway prior to the attack, but subsequent to it there has been a concerted effort by the major WLAN vendors and a team of cryptographers to develop a fix for WEP that can be deployed on most of the current WLAN cards. These fixes are being designed to provide real security and meet the true per-packet authentication needs of WLAN.
WEP fixes are currently being addressed in the IEEE 802.11i working group. There will be two fixes to WEP. The first is a fix that works within capabilities of the current hardware, which in the remainder of this paper we call TKIP (Temporal Key Integrity Protocol). The second set of changes will not be constrained to existing hardware limitations. The second set is referred to as CCMP (Counter-Mode/CBC-MAC protocol) in the remainder of this paper. The standards process is slow and both vendors and customers need an interim fix. This is the WiFi Protected Access WPA, which is based on a draft version of TKIP see section 2.4.1.4.
TKIP for fixing current hardware
Limitations with current hardware include the lack of a multiply function (needed by most crytpo algorithms), the RC4 algorithm implemented in hardware, and limited hardware support for security formatting. TKIP will have to fit into the 4 key model in the 1999 specification that restrains the rekeying process.TKIP has evolved extensively since it was first proposed in November 2001. TKIP is fairly complex, as it has to work within some severe design constraints. These include:
- Memory and CPU limited devices
- RC4 encryption with a problematic key scheduler (component of RC4 that produces the per-packet encrypting information)
- Limited field size for a strong Message Integrity Check
- Limited key storage model
There are five key elements in TKIP: use of 802.1x for authentication, an 802.1x based keying mechanism using the key established by an EAP method over 802.1x, an RC4 key mixing process with a 48 bit IV, and a MIC (message integrity check).
802.1x authentication with TKIP
TKIP has a reasonable set of requirements on the EAP method used with 802.1x:
- Resilient to Man in the Middle and offline dictionary attacks
- Provide mutual authentication of the AS and STA
- Ends with a secret key shared by the AP and STA
EAP types that meet these requirements include PEAP, TLS, and TTLS.
Rekeying with TKIP
TKIP rekeying requirements are based on the size of the Initialization Vector (IV). With a 48 bit IV, this is considered large enough that 802.1X authentication will occur before the IV space is exhausted.
Pre-TKIP—WPA
WPA is an interim security standard of the WiFi Alliance. It was extracted from a draft of IEEE 802.11i. It is TKIP without the following components:
- IBSS support
- Pre-Authentication for fast roaming support
- QOS support
WPA will present a series of challenges:
- Will TKIP ever get fielded once WPA gets a market foothold?
- If flaws are found in WPA will it impact the credibility of the WiFi Alliance and the IEEE?
- Can WPA become the proving ground for TKIP to improve its security strength and thus market success?
Both WPA and TKIP are viewed as best-effort fixes for the current RC4-based 802.11 hardware.
Some of the issues noted earlier with 802.1x are directly addressed with TKIP.
With the current WEP, 802.1x APs and STAs are using the EAPOL-Key packet to supply the STA with WEP link broadcast/multicast keys. TKIP continues to use the EAPOL-Key packet but in a new format and in a new protocol that is resilient to attacks.
The inclusion of a replay counter and the Message Integrity Code (MIC) defeats all known authentication and substitution attacks. However, it must be applied to some of the WLAN MAC sublayer management frames like disassociation and reassociation in addition to data frames. TKIP does authenticate sublayer management frames where possible. This lessens the management frame attacks, but does not eliminate them.
CCMP—Total WEP replacement
The effort to create a WEP fix for the current hardware platforms will move on to a total replacement of WEP for new, more powerful hardware platforms. It is likely that CCMP, Counter-Mode/CBC-MAC protocol will not work on many of the current shipping cards. CCMP is AES based and many cards lack a multiply function needed by AES. Cards that have the multiply function may lack either the processing power or the memory to support AES. Thus TKIP will have a long field life and CCMP will need to interoperate with TKIP.
The CCMP will have a limited number of encipherment suites based on AES and a few MIC algorithms. Disagreement between WLAN vendors has hampered efforts to have only one suite.
The current 802.11 standard does not deal adequately with WLAN access control and authentication. The framework is good; 802.11 specifies the use of 802.1x and RADIUS/EAP (or other AAA protocol supporting EAP) to provide mutual authentication of the STA and the Network RADIUS server (AS). However, the 802.11 standards group has not provided any recommendations for a standard authentication protocol to be carried by 802.1x and RADIUS/EAP.
The issues with existing per frame standards include the well-documented and publicized problems with WEP. From the Authentication view, the most important issue is to be sure that message integrity is implemented for every packet. Without it, connections can be hijacked by impersonating the MAC address of the STA. This means that the authentication must be bound to a session key (which may be used as a WEP key, or be bound itself to a WEP key).
The combination of a need for WEP and the requirement for authentication to provide dynamic WEP keys leads to the conclusion that to provide secure connections each new wireless LAN access must be authenticated and the authentication should result in a unique shared session key. The session key is used to provide message integrity between the STA and the AP.
Access authentication is a critical part of secure wireless access. It helps with the current WEP weakness and is needed for managing secure access when a WEP replacement is available. The IEEE 802.11 group has provided a framework for access authentication and is fixing problems with WEP. For Wireless LAN authentication to be successfully rolled out, however, additional authentication protocols that work with 802.1x and EAP must also be developed and deployed.
Appendix – Glossary
AAA. Authentication, Authorization and Accounting. AAA server (frequently a RADIUS server) performs these functions, processing requests using a AAA protocol such as RADIUS.
AES. Advanced Encryption System – An encryption method based on the Rijndael algorithm that will be the basis for future wireless encryption standards.
AP. Access Point – A wireless station that also provides services such as association and distribution of frames to other station or a network.
AS. Authentication Server – A network component that performs authentication. A RADIUS server is an example of an AS.
Authenticator. 802.1X term for an entity that facilitates authentication. Access points act as authenticators.
BSSID. Basic Service Set Identifier – A unique identifier for a particular BSS. In infrastructure mode, the MAC address of an access point.
CA. Certificate Authority – An authority that issues and manages digital security credentials such as public-key certificates.
COPS – Common Open Policy Service – A protocol used for policy control and provisioning.
CRL. Certificate Revocation List – A list of client certificates that were revoked by the authority before they expired.
EAP. Extensible Authentication Protocol – A general protocol for authentication that supports multiple authentication mechanisms.
EAPOL. EAP Over LAN - A technique to encapsulate EAP packets in a LAN environment.
IAPP. Inter-Access Point Protocol – A protocol for communicating information between access points in order to support roaming.
IEEE. Institute of Electrical and Electronics Engineers - A non-profit, technical professional association for electrical and electronics engineering.
IETF. Internet Engineering Task Force - The principal body engaged in the development of new Internet standard specifications.
LEAP. Lightweight EAP – A Cisco vendor-specific authentication method that provides mutual authentication and dynamic WEP key generation.
PKI. Public Key Infrastructure – A configuration of systems and components required to manage and administer a public key environment.
RADIUS. Remote Authentication Dial-in User Service – a protocol used to perform authentication, authorization, and accounting (AAA).
RADIUS Server. AAA server or Authetication Server (AS) that provides user authentication, authorization, and accounting (AAA)
RC4. A variable key-size stream cipher with byte oriented operations. A registered trademark of RSA Security Inc.
SLP. Service Locator Protocol – A protocol which provides a method to discover and select network services.
SSID. Service Set Identifier – An arbitrary string naming an access point or set of access points for purposes of identifying the WLAN to clients.
STA. Wireless Station – Any 802.11 device other than an AP.
Supplicant. 802.1X term for an entity that is being authenticated. Often a synonym for client, workstation, or user.
TLS. Transport Layer Security – A protocol designed to provide privacy and data integrity between two communicating applications. Specifically, EAP-TLS provides protected ciphersuite negotiation, mutual authentication, and key management.
VPN. Virtual Private Network - A method of using encryption and tunneling to securely connect users over a public network.
WEP. Wired Equivalent Privacy – An 802.11 privacy service that encrypts data sent over the wireless medium.
WLAN. Wireless Local Area Network – A network that provides the features of traditional LAN technologies such as Ethernet and Token Ring using wireless technology.
X.509. An International Telecommunications Union (ITU) standard specifying the contents of a digital certificate.
|
