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 under-
stand the shortcomings of WEP .
WEP’s failings
Wireless networks based on 802.11 have been
plagued by some well-publicized security fail-
ings. The Wireless Equivalent Privacy (WEP)
encryption built into 802.11 can be compro-
mised 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. Tradition-
ally, keys are delivered through some alternate
communication method, usually involving a
wired network that is considered to be secure.
Key distribution is one management prob-
lem associated with WEP that causes adminis-
trative and security headaches. Another is man-
agement 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 be-
cause most managers administer their access-
control 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 MAC-
addresses 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 secu-
rity structure in wireless networks is flawed as
well. Instead of being able to leverage the exist-
ing corporate infrastructure for user-based au-
thentication, administrators are forced to allow
access on the basis of keys without a distribu-
tion mechanism and on hardware addresses.
IEEE 802.1X’s promise
IEEE 802.1X is an IEEE standard for “Port-
Based Network Access Control.” It allows the
decision of whether or not to permit network-
access 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 man-
agement, 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 authen-
tication 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 struc-
ture. Another example is EAP-OTP, which speci-
fies 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 au-
thenticator to the authentication server.
In an optimal configuration, this server is
centralized and shared. Remote Authentication
Dial In User Service (RADIUS) has been a nat-
ural choice here. Many network infrastructures
already contain RADIUS servers for verifying
dial-in users. Allowing them to authenticate
other forms of network access, including wire-
less, is a natural sharing of an already central-
ized 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.
The marketplace makes everything messier
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 imple-
mentations. 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 communi-
cation protocol, but instead developed their
own EAP method: EAP-Cisco Wireless or
Lightweight EAP (LEAP).
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
LAN.” The 802.11a specification provides details for the 5.7 gigahertz band allowing 54 Mbps
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 is-
sues, 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 com-
plete 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 in-
volve 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 deploy-
ment, 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 wire-
less 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 sta-
tion device such as a PDA or laptop. The device
“guarding” access to the network and enforc-
ing the need for authentication is the authenti-
cator. 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 authenti-
cation 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 authentica-
tors (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 gen-
eral structure. The supplicant sends an EAPOL-
Start packet to indicate it wishes to be authenti-
cated. The authenticator then sends an
EAP-Request/Identity to determine which user
wishes access. The authenticator may send this
 cannot secure delivery of key updates. Follow-
802.1X ROLES
ing that, we can tackle more complex protocols
such as EAP-TLS and LEAP.
There are three roles in 802.1X:
The simple challenge-response is much like
• Supplicant: An end device requesting access to a 802.1X protected network. Laptops, PDAs, and so on. are
CHAP and RFC 1994, with MD5 and RFC 1321.
common supplicants. The supplicant must properly complete the exchange with the authenticator in EAPOL in
Note, following the initial Identity request
order to gain access to the network. Hence, the supplicant must contain the EAPOL protocol, the supplicant
and response, there is only one request (the
state machines and at least one of the specific EAP authentication methods that the authenticator/
challenge from the authentication server)
authentication server of the protected network support. If the EAP method supports it, the supplicant may, in
and one supplicant response before the access
conjunction with the authentication server, generate the “session key” that will be used to encrypt encryption
decision is delivered to the supplicant.
keys delivered to it.
• Authenticator: Typically implemented on an access point, switch or router. This role communicates with that of EAP-TLS
the supplicant in EAPOL. The authenticator’s communication with the authentication server is generally done EAP-TLS was Microsoft’s choice for including
in RADIUS. Hence, the authenticator includes the EAPOL protocol, the authenticator state machines and 802.1X support in Windows XP. TLS is the same
whatever is needed to communicate to the authentication server, typically a RADIUS client. Between initially well-tested security used for online Web-based
engaging a supplicant and completing the authentication process, much of what the authenticator does is transactions. As such, it requires certificates
moving EAP packets between the supplicant (in EAPOL) and the authentication server (typically in RADIUS). and the somewhat heavy infrastructure to cre-
While the authenticator has carried all the traffic between the supplicant and authentication server it does ate, deploy, and verify these certificates. At a
not know the private passwords or certificates used to generate the session key. Following a successful minimum, client certificates must be deployed
authentication, the authenticator receives the session key from the authentication server and distributes (or to supplicants so that the supplicants can prove
indicates) the encryption keys for unicast and multicast traffic. that they are indeed authenticated to access the
• Authentication server: Generally a RADIUS server authenticates users. It derives the session key in network. Server certificates should also be used
conjunction with the supplicant, and, following a successful authentication, delivers the key to the to take advantage of the mutual authentication
authenticator. As long as the RADIUS server supports the RFC 2869 extensions for EAP, and the required available, and prevent “rogue access points”
EAP authentication method, no additional components are mandated here by the 802.1X standard. from fooling supplicants into accessing the
wrong network.
The EAP-TLS conversation is more compli-
cated than that of EAP-MD5, and the details are
message upon initially detecting a supplicant If the authentication succeeds, the RADIUS not covered here. It begins as all 802.1X EAP
without having received the EAPOL-Start mes- server delivers an Access-Accept to the authenti- conversations do, then is followed by TLS start
sage. This will occur when the port is activated, cator, and the authenticator can indicate and hello messages. Certificates are then ex-
as when the 802.11 layer association and au- EAP-Success to the supplicant. If a session key changed and verified, cipher suites negotiated,
thentication is complete. The supplicant identi- has been derived as a result of the EAP method, and finally access is granted, with the session
fies itself with an EAP-Response/Identity re- it will generally be delivered with the Access- key delivered to the authenticator as an MS-
sponse. The authenticator puts the response Accept as a Microsoft or Cisco vendor-specific MPPE attribute. As is the general case when a
into a RADIUS Access-Request to the server. attribute. If the authentication fails, the session key is available, EAPOL Key messages
At this point, a sequence of EAP-Requests authentication server delivers an Access-Reject are delivered from the authenticator to the sup-
and EAP-Responses that are specific to the EAP to the authenticator, which generates an plicant. The multicast key is generated by the
method ensue: EAP-Failure message to the supplicant. access point from random numbers, and is
•from the server in RADIUS to the authentica- encrypted by the session key. The unicast key
tor EAP-MD5 is typically an EAPOL Key message without a
•in EAPOL from authenticator to supplicant Let’s look at EAP-MD5. Its simplicity makes it a key included, indicating that the session key
•in EAPOL from supplicant to authenticator, good starting point to understand what is going itself should be used as the WEP key for
and on, although it is inappropriate for wireless be- unicast traffic.
•from authenticator to authentication server cause it does not generate session keys and thus
in RADIUS.

EAP-MD5
Supplicant Authenticator Authentication
Server
EAPOL RADIUS
EAPOL-Start
EAP-Request/Identity
EAP-Response/Identity
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 from the authentication server and responses
LEAP is Cisco’s proprietary EAP method. The from the supplicant, and as a result cannot ac-
“L” in LEAP is for lightweight. While it provides commodate LEAP’s symmetric traffic. In addi-
mutual authentication and generates a session tion, Cisco uses the term LEAP to apply not only
key (making it appropriate for wireless use), it to the EAP authentication method, but to
does not require certificates and the burden of changes in 802.11b’s own authentication val-
their infrastructure. Instead, LEAP is password- ues. Hence implementing LEAP may require
based. further control to the underlying 802.11 hard-
LEAP is a “symmetric” challenge and re- ware than other EAP methods.
sponse. The supplicant and then the authenti-
cation server each generate a challenge and EAP-TTLS and PEAP
verify the other’s response. A session key is gen- Two new EAP methods have recently emerged
erated from a combination of these challenges, that combine the security of EAP-TLS and the
their responses, and a password. simplicity of LEAP. Both EAP-TTLS (Tunneled
While LEAP seems to provide all the benefits TLS) and PEAP (Protected EAP) use TLS. But
without the impact of certificates, it does have a they only use TLS with server certificates to set
downside. LEAP is Cisco-proprietary and not
widely handled. 802.1X standard defined state
machines are designed to pass only requests
up a secure channel, and let the supplicant ver-
ify 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 in-
ner algorithm must be an EAP method. Efforts
are underway to standardize between the two.
802.1X’s Failings?
In February, 2002, a paper* was published from
the University of Maryland detailing problems
with 802.1X. This paper generated a lot of at-
tention, 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 de-
vices capable of accessing today’s secured wire-
less 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 con-
forming EAP method, but also to include mod-
ifications necessary in order to include LEAP
 HOW SMART THINGS THINK ™

amongst the supported protocols. Integration

EAP-TLS efforts with Wind River’s 802.11 offering assure
Supplicant Authenticator Authentication that LEAP’s variations at the 802.11 layer can
Server be accounted for as well. For additional
EAPOL RADIUS manageability of the authenticator/access
point, there is support for 802.11 and 802.1X
EAPOL-Start
EAP-Request/Identity
MIBs and optional use of Envoy Epilogue
EAP-Response/Identity SNMP 9.2.
Access-Request Wind River’s supplicant provides an
EAP-Response/Identity architecture currently supporting LEAP while
Access-Challenge
EAP-Request/TLS-Start
allowing additional EAP methods to be added.
EAP-Request/TLS-Start
EAP-Response/TLS-client_hello Summary
Access-Request
Due to the failings of WEP’s security mecha-
EAP-Response/TLS-client_hello
Access-Challenge nism, additional layers must be employed. De-
EAP-Request/TLS-{server_hello, ployment of effective security cannot wait for
certificate,server_key_exchange, upcoming amendments from the IEEE stan-
certificate_request,
server_hello_done}
dards bodies. While 802.1X will be part of the
EAP-Request/TLS-{server_hello, 802.11i amendments, it is being used effectively
certificate,server_key_exchange, for its increased security and management
certificate_request, benefits. While a deployment requires adminis-
server_hello_done}
EAP-Response/TLS-{certificate,
trators to consider infrastructure costs and in-
client_key_exchange, teroperability, the technology is presently avail-
certificate_verify, able, and deploying a wireless network without
change_cipher_spec,finished}
it would be a critical oversight.
Access-Request
EAP-Response/TLS-{certificate,
client_key_exchange, For more information
certificate_verify, Wind River currently offers leading-edge
change_cipher_spec,finished}
Access-Challenge
802.1X technology. For more information, con-
EAP-Request/TLS-{ tact your local Wind River sales representative
change_cipher_spec,finished} at 1-800-545-9463. Outside the U.S., contact
EAP-Request/TLS-{ the Wind River sales office nearest you.
change_cipher_spec,finished}
EAP-Response/TLS
Access-Request
EAP-Response/TLS
Access-Accept
MS-MPPE-Send-Key
EAP-Success
EAPOL-Key
RC4/indexA-multi *”An Initial Security Analysis of the IEEE 802.1X Standard,”
Arunesh Mishra and William A. Arbaugh, University of
EAPOL-Key Maryland, Feb. 2002.
RC4/indexC-uni

Wind River Worldwide Headquarters Tornado, VxWorks, Wind River and the Wind River logo are trademarks,
500 Wind River Way registered trademarks, or service marks of Wind River Systems, Inc., or its
subsidiaries. All other names mentioned are trademarks, registered trademarks,
Alameda, CA 94501 USA
or service marks of their respective companies.
Toll free 1-800-545-WIND
Phone 1-510-748-4100 ©2002 Wind River Systems MCL-WHP-80X-0208
Fax 1-510-749-2010
Inquiries@windriver.com
Nasdaq: WIND
For additional contact information,
please see our Web site at www.windriver.com.