Wind River
White paper
IEEE 802.1X in Secure Wireless Networking Applying the IEEE 802.1X protocol to wireless networking in conjunction with 802.11 dramatically simplifies the management of secure wireless LANs. The IEEE 802.1X protocol can also be used to manage policy-based bandwidth provisioning and VLAN support in conjunction with 802.11e. This paper examines and explores the current application of 802.1X to wireless networking situations, its important role in today’s network security, and future directions for the protocol. Gilbert Goodwill Member of Technical Staff Digital Consumer Group
HOW SMART THINGS THINK ™
Wireless security
Network security in a wireless LAN environment is a unique challenge. Network administrators face the security challenges of traditional wired networks plus additional burdens as a result of the range (often wider than intended) of wireless networks. As in wired networks, basic controls needed include: •A host system that authenticates the user or device attempting to access the network •Encryption that protects the data as it travels from the user device to the access point, whether to ensure confidentiality or to ensure that no one has tampered with the message and changed its content The IEEE 802.1X protocol provides a different approach to security and security management that overcomes the failings of 802.11 Wired Equivalent Privacy (WEP). To appreciate the advantages of 802.1X fully, we must first understand the shortcomings of WEP . WEP’s failings
Wireless networks based on 802.11 have been plagued by some well-publicized security failings. The Wireless Equivalent Privacy (WEP) encryption built into 802.11 can be compromised relatively easily. Wireless sniffing programs, such as AirSnort, can implement attacks that exploit these weaknesses. By gathering enough “interesting” packets, i.e. those that contain weak initialization vectors (starting keys), these sniffers can decrypt WEP-encoded messages by breaking the keys employed by WEP. Some vendors are trying to fix this problem through firmware updates that provide “weak key avoidance.” Unfortunately, it only takes one piece of hardware accessing the network without these upgrades to compromise the network. Another way of deflecting these attacks is to change the WEP keys periodically. Before an attacker can gather enough information to deduce the keys, the keys themselves change.
Unfortunately, WEP does not provide a facility to distribute keys to deployed devices. Traditionally, keys are delivered through some alternate communication method, usually involving a wired network that is considered to be secure. Key distribution is one management problem associated with WEP that causes administrative and security headaches. Another is management of authorization for deployed devices. Device management is usually done through MAC addresses. A deployed wireless network allows or disallows access to the network by checking the requester’s MAC address against an access-control list. Complications arise because most managers administer their accesscontrol lists at individual access points rather than through a centralized database. This decentralized approach gives rise to a large number of lists. If hardware is lost or stolen, updating the access points individually is time consuming. Also, access control via MACaddresses has a greater problem: MAC-address spoofing is relatively trivial for the determined hacker or espionage agent to implement. As the above issues illustrate, not only is security flawed, but administration of the security structure in wireless networks is flawed as well. Instead of being able to leverage the existing corporate infrastructure for user-based authentication, administrators are forced to allow access on the basis of keys without a distribution mechanism and on hardware addresses. IEEE 802.1X’s promise
IEEE 802.1X is an IEEE standard for “PortBased Network Access Control.” It allows the decision of whether or not to permit networkaccess to be made at the port, the point of contact to the network itself. Until a port is authenticated, it can be used only to pass traffic associated with the authentication process. Authentication can be user-based and managed at a centralized authentication server. In addition, 802.1X provides optional abilities to distribute keys.
With its combination of centralized management, management by user instead of device, network protection and key delivery, 802.1X seems to be the prescription for correcting WEP’s failings. Using 802.1X
The 802.1X protocol specifies Extensible Authentication Protocol (EAP) to carry authentication messages. As the term “Extensible” implies, EAP can carry any number of actual authentication protocols. One example of an EAP authentication method is EAP-TLS. This protocol packages Transport Layer Security (TLS), an evolution of the Secure Sockets Layer (SSL) used in secure Web browsing, on top of EAP’s message structure. Another example is EAP-OTP, which specifies use of “one time passwords.” For successful authentication, the entity requesting access to the network and the network’s infrastructure must both support the same EAP “flavor.” The marketplace responds
IEEE 802.1X specifies a new protocol – EAP Over LAN (EAPOL) – for carrying EAP between the supplicant and the protected access point to the network (the authenticator). However, it does not specify how to carry EAP from the authenticator to the authentication server. In an optimal configuration, this server is centralized and shared. Remote Authentication Dial In User Service (RADIUS) has been a natural choice here. Many network infrastructures already contain RADIUS servers for verifying dial-in users. Allowing them to authenticate other forms of network access, including wireless, is a natural sharing of an already centralized resource. While the use of RADIUS is only suggested by the IEEE, it has quickly become the de facto authentication server to be used in conjunction with 802.1X. Even the key delivery portion of 802.1X is not completely described in the standard. While it is clear the EAPOL contains the ability to deliver keys in its EAPOL-Key messages, the de-
tails of how these keys are derived, when these key messages are sent, and how the setting of keys is synchronized between entities are not specified.
PROTOCOL PRIMER
The IEEE protocols involved are IEEE 802.11 and 802.1X. IEEE 802.11 is “Wireless LAN Medium Access Control and Physical Layer Specifications.” This is what is often referred to as “wireless
The marketplace makes everything messier
LAN.” The 802.11a specification provides details for the 5.7 gigahertz band allowing 54 Mbps
It has been said, “Wherever a standard is needed at least two will be created.” In the absence of a complete specification of how to use 802.1X in conjunction with 802.11, several manufacturers came up with their own implementations. Microsoft rolled out 802.1X in their Windows XP using EAP-TLS as the EAP method and RADIUS as the communication to the server. Cisco Systems also chose RADIUS as the authenticator-authentication server communication protocol, but instead developed their own EAP method: EAP-Cisco Wireless or Lightweight EAP (LEAP).
throughput. 802.11b and newer 802.11g are for the 2.4 gigahertz band with an 11 Mbps and 54 Mbps throughput, respectively. IEEE 802.1X-2001, approved in June of 2001, defines the standard described above including the supplicant, authenticator and authentication server roles, EAPOL protocol and associated state machines. Several IETF RFCs are relevant to the use of 802.1X and its use with 802.11. RFC 2284 defines EAP for use with PPP. EAP is used in other scenarios, including port authentication in 802.1X and extensions to RADIUS, RFC 2869. EAP is a simple protocol with four packet types: request, response, success, and failure. The actual protocol “carried” by EAP is not defined in RFC 2284. It initially defined types for MD5 (like CHAP, RFC 1994, 2433, 2759), one-time passwords (OTP), and generic token cards (GTC). RFC 2716 defines EAP-TLS to carry TLS on EAP. Cisco’s LEAP is proprietary and hence does not have a corresponding RFC. Drafts for other EAP methods include EAP-SecurID, EAP-SIM, EAP-SKE, EAP-TTLS, EAP-GSS.
Standard bodies respond as well
IEEE 802.11 has a task group for security issues, Task Group I (TGi) developing what will become 802.11i. The failings of the original security in the WEP specification have made TGi cautious about releasing another flawed model. They have been torn between a complete solution that requires deploying new hardware, and a “patch” solution that gives adequate security without making current hardware obsolete. In the meantime, the Cisco and Microsoft-backed solutions, as well as others, gained rapid acceptance. In the wake of publicity about the WEP failings, corporations and institutions seek to secure their networks and still offer the flexibility of wireless access. Other approaches
There are other security options that do not involve 802.1X. Intel and Colubris have each put out white papers suggesting the use of Virtual Private Network (VPN) technologies such as IPSec on top of 802.11. Others, such as Symbol, suggest the use of Kerberos instead. These pro-
tocols are considered quite secure but involve tradeoffs in their use, such as cost of deployment, computational burden, and throughput overhead. VPN type solutions often encrypt only at the IP layer, and hence non-IP traffic is not secured. In addition, the endpoints of VPN communication usually extend past the wireless access point causing an additional burden on infrastructure. 802.1X roles and protocols
There are three roles in 802.1X. While these roles correspond nicely to some of those used in 802.11, they do not share the same names. The device requesting access to the network is the supplicant. The supplicant, in 802.11, is a station device such as a PDA or laptop. The device “guarding” access to the network and enforcing the need for authentication is the authenticator. The authenticator in 802.11 is an access point – the junction between the protected (wired) and unprotected (wireless) networks. The final role in 802.1X is that of the authentication server. While the standard does allow this to be co-located with the authenticator,
that would eliminate the benefit of having a single authentication server centrally located and managed being used by many authenticators (access points). The authentication server is in most cases a RADIUS server supporting the RADIUS extensions for EAP. Comparing authentication in different EAP methods
Looking at some of the details of EAP methods used in conjunction with 802.1X will help to clarify some of the differences, advantages, and disadvantages among them. Common framework for 802.1X authentication
Regardless of EAP method, all authentication conversations on 802.1X follow the same general structure. The supplicant sends an EAPOLStart packet to indicate it wishes to be authenticated. The authenticator then sends an EAP-Request/Identity to determine which user wishes access. The authenticator may send this
802.1X ROLES
There are three roles in 802.1X: • Supplicant: An end device requesting access to a 802.1X protected network. Laptops, PDAs, and so on. are common supplicants. The supplicant must properly complete the exchange with the authenticator in EAPOL in order to gain access to the network. Hence, the supplicant must contain the EAPOL protocol, the supplicant state machines and at least one of the specific EAP authentication methods that the authenticator/ authentication server of the protected network support. If the EAP method supports it, the supplicant may, in conjunction with the authentication server, generate the “session key” that will be used to encrypt encryption keys delivered to it. • Authenticator: Typically implemented on an access point, switch or router. This role communicates with that of the supplicant in EAPOL. The authenticator’s communication with the authentication server is generally done in RADIUS. Hence, the authenticator includes the EAPOL protocol, the authenticator state machines and whatever is needed to communicate to the authentication server, typically a RADIUS client. Between initially engaging a supplicant and completing the authentication process, much of what the authenticator does is moving EAP packets between the supplicant (in EAPOL) and the authentication server (typically in RADIUS). While the authenticator has carried all the traffic between the supplicant and authentication server it does not know the private passwords or certificates used to generate the session key. Following a successful authentication, the authenticator receives the session key from the authentication server and distributes (or indicates) the encryption keys for unicast and multicast traffic. • Authentication server: Generally a RADIUS server authenticates users. It derives the session key in conjunction with the supplicant, and, following a successful authentication, delivers the key to the authenticator. As long as the RADIUS server supports the RFC 2869 extensions for EAP, and the required EAP authentication method, no additional components are mandated here by the 802.1X standard.
message upon initially detecting a supplicant without having received the EAPOL-Start message. This will occur when the port is activated, as when the 802.11 layer association and authentication is complete. The supplicant identifies itself with an EAP-Response/Identity response. The authenticator puts the response into a RADIUS Access-Request to the server. At this point, a sequence of EAP-Requests and EAP-Responses that are specific to the EAP method ensue: •from the server in RADIUS to the authenticator •in EAPOL from authenticator to supplicant •in EAPOL from supplicant to authenticator, and •from authenticator to authentication server in RADIUS.
If the authentication succeeds, the RADIUS server delivers an Access-Accept to the authenticator, and the authenticator can indicate EAP-Success to the supplicant. If a session key has been derived as a result of the EAP method, it will generally be delivered with the AccessAccept as a Microsoft or Cisco vendor-specific attribute. If the authentication fails, the authentication server delivers an Access-Reject to the authenticator, which generates an EAP-Failure message to the supplicant. EAP-MD5
Let’s look at EAP-MD5. Its simplicity makes it a good starting point to understand what is going on, although it is inappropriate for wireless because it does not generate session keys and thus
cannot secure delivery of key updates. Following that, we can tackle more complex protocols such as EAP-TLS and LEAP. The simple challenge-response is much like CHAP and RFC 1994, with MD5 and RFC 1321. Note, following the initial Identity request and response, there is only one request (the challenge from the authentication server) and one supplicant response before the access decision is delivered to the supplicant. EAP-TLS
EAP-TLS was Microsoft’s choice for including 802.1X support in Windows XP. TLS is the same well-tested security used for online Web-based transactions. As such, it requires certificates and the somewhat heavy infrastructure to create, deploy, and verify these certificates. At a minimum, client certificates must be deployed to supplicants so that the supplicants can prove that they are indeed authenticated to access the network. Server certificates should also be used to take advantage of the mutual authentication available, and prevent “rogue access points” from fooling supplicants into accessing the wrong network. The EAP-TLS conversation is more complicated than that of EAP-MD5, and the details are not covered here. It begins as all 802.1X EAP conversations do, then is followed by TLS start and hello messages. Certificates are then exchanged and verified, cipher suites negotiated, and finally access is granted, with the session key delivered to the authenticator as an MSMPPE attribute. As is the general case when a session key is available, EAPOL Key messages are delivered from the authenticator to the supplicant. The multicast key is generated by the access point from random numbers, and is encrypted by the session key. The unicast key is typically an EAPOL Key message without a key included, indicating that the session key itself should be used as the WEP key for unicast traffic.
EAP-MD5
Supplicant
Authenticator EAPOL
Authentication Server RADIUS
EAPOL-Start EAP-Request/Identity EAP-Response/Identity
up a secure channel, and let the supplicant verify it is not dealing with a rogue access point. Once TLS server certificates establish the “tunnel,” both EAP-TTLS and PEAP run an “inner” authentication algorithm with that tunnel. In EAP-TTLS, the inner algorithm can be of any sort: PAP, CHAP, etc. In PEAP the inner algorithm must be an EAP method. Efforts are underway to standardize between the two. 802.1X’s Failings?
Access-Request EAP-Response/Identity Access-Challenge EAP-Request/MD5-Challenge EAP-Request/MD5-Challenge EAP-Response/MD5-Response Access-Request EAP-Response/MD5-Response Access-Accept EAP-Success
LEAP
LEAP is Cisco’s proprietary EAP method. The “L” in LEAP is for lightweight. While it provides mutual authentication and generates a session key (making it appropriate for wireless use), it does not require certificates and the burden of their infrastructure. Instead, LEAP is passwordbased. LEAP is a “symmetric” challenge and response. The supplicant and then the authentication server each generate a challenge and verify the other’s response. A session key is generated from a combination of these challenges, their responses, and a password. While LEAP seems to provide all the benefits without the impact of certificates, it does have a downside. LEAP is Cisco-proprietary and not widely handled. 802.1X standard defined state machines are designed to pass only requests
from the authentication server and responses from the supplicant, and as a result cannot accommodate LEAP’s symmetric traffic. In addition, Cisco uses the term LEAP to apply not only to the EAP authentication method, but to changes in 802.11b’s own authentication values. Hence implementing LEAP may require further control to the underlying 802.11 hardware than other EAP methods. EAP-TTLS and PEAP
Two new EAP methods have recently emerged that combine the security of EAP-TLS and the simplicity of LEAP. Both EAP-TTLS (Tunneled TLS) and PEAP (Protected EAP) use TLS. But they only use TLS with server certificates to set
In February, 2002, a paper* was published from the University of Maryland detailing problems with 802.1X. This paper generated a lot of attention, as 802.1X had seemed to be prescribed for the security problems in 802.11 and now was subject to its own failings. Fortunately, the specific attacks described in the paper can be mitigated by proper use of 802.1X. The attacks described do not allow unwanted access to the network or eavesdropping of encrypted data. They do allow denial of service and interfering with proper network access. IEEE 802.11i is working on some of the issues relating to tying 802.11 and 802.1X’s state machines together. IEEE 802.1aa also proposes amendments to 802.1X to clarify ambiguities in the original standard. Wind River’s offerings for wireless security
Wind River’s WindNet™ 802.1X provides both supplicant and authenticator roles for 802.1X. The supplicant can be combined with WindNet 802.11b Device Driver Kit (DDK) to create devices capable of accessing today’s secured wireless network. In combination with WindNet 802.11b DDK and WindNet RADIUS Client, WindNet 802.1X provides a complete solution for creating secure access points. Wind River’s authenticator role design allows any EAP method to pass between the supplicant and authentication server. The authentication state machines are generic enough to handle any 802.1X standard conforming EAP method, but also to include modifications necessary in order to include LEAP
HOW SMART THINGS THINK ™
EAP-TLS
Supplicant
Authenticator EAPOL
Authentication Server RADIUS
EAPOL-Start EAP-Request/Identity EAP-Response/Identity Access-Request EAP-Response/Identity Access-Challenge EAP-Request/TLS-Start EAP-Request/TLS-Start EAP-Response/TLS-client_hello
amongst the supported protocols. Integration efforts with Wind River’s 802.11 offering assure that LEAP’s variations at the 802.11 layer can be accounted for as well. For additional manageability of the authenticator/access point, there is support for 802.11 and 802.1X MIBs and optional use of Envoy Epilogue SNMP 9.2. Wind River’s supplicant provides an architecture currently supporting LEAP while allowing additional EAP methods to be added. Summary
Access-Request EAP-Response/TLS-client_hello Access-Challenge EAP-Request/TLS-{server_hello, certificate,server_key_exchange, certificate_request, server_hello_done} EAP-Request/TLS-{server_hello, certificate,server_key_exchange, certificate_request, server_hello_done} EAP-Response/TLS-{certificate, client_key_exchange, certificate_verify, change_cipher_spec,finished} Access-Request EAP-Response/TLS-{certificate, client_key_exchange, certificate_verify, change_cipher_spec,finished} Access-Challenge EAP-Request/TLS-{ change_cipher_spec,finished} EAP-Request/TLS-{ change_cipher_spec,finished} EAP-Response/TLS
Due to the failings of WEP’s security mechanism, additional layers must be employed. Deployment of effective security cannot wait for upcoming amendments from the IEEE standards bodies. While 802.1X will be part of the 802.11i amendments, it is being used effectively for its increased security and management benefits. While a deployment requires administrators to consider infrastructure costs and interoperability, the technology is presently available, and deploying a wireless network without it would be a critical oversight. For more information
Wind River currently offers leading-edge 802.1X technology. For more information, contact your local Wind River sales representative at 1-800-545-9463. Outside the U.S., contact the Wind River sales office nearest you.
Access-Request EAP-Response/TLS Access-Accept MS-MPPE-Send-Key EAP-Success EAPOL-Key RC4/indexA-multi EAPOL-Key RC4/indexC-uni
Wind River Worldwide Headquarters 500 Wind River Way Alameda, CA 94501 USA Toll free 1-800-545-WIND Phone 1-510-748-4100 Fax 1-510-749-2010
[email protected] Nasdaq: WIND For additional contact information, please see our Web site at www.windriver.com.
*”An Initial Security Analysis of the IEEE 802.1X Standard,” Arunesh Mishra and William A. Arbaugh, University of Maryland, Feb. 2002.
Tornado, VxWorks, Wind River and the Wind River logo are trademarks, registered trademarks, or service marks of Wind River Systems, Inc., or its subsidiaries. All other names mentioned are trademarks, registered trademarks, or service marks of their respective companies. ©2002 Wind River Systems
MCL-WHP-80X-0208