802.1x and EAP—Advanced Security

802.1x and EAP—Advanced Security
802.1x provides an authentication framework for WLANs, enabling a user to be authenticated by a central
authority. The actual algorithm that is used to determine whether a user is authentic is left open and
multiple algorithms are possible. Examples are certificate-based solutions (such as EAP—Transport
Layer Security [EAP-TLS]), password-based solutions (such as EAP-One Time Password [EAP-OTP]
and EAP-Message Digest 5 [EAP-MD5]), smart-card-based solutions (such as EAP—Subscriber
Identification Module [EAP-SIM]), and hybrids (such as EAP-Tunneled TLS Authentication Protocol [EAPTTLS])
that use both certificates and passwords. Some companies offer their own proprietary EAP
solution, such as Cisco's Lightweight EAP (LEAP).
802.1x uses EAP, an existing protocol (RFC 2284) that works on Ethernet, Token Ring, or WLANs for
message exchange during the authentication process.
802.1x Network Port Authentication 802.1x authentication for WLANs has three main components: the
supplicant (usually the client software), the authenticator (usually the AP), and the AS (usually a RADIUS
server, although RADIUS is not specifically required by 802.1x).[15] The authenticator connects to the
LAN network. Figure 4-14 illustrates this process.
Figure 4-14: 802.1x authentication
The normal flow for an 802.11x authentication is as follows: The supplicant (in the client) tries to connect
to the AP by sending a start message. The AP detects the supplicant and enables the supplicant's port in
an unauthorized state, so only 802.1x/EAP messages are forwarded. All other traffic is blocked.
The supplicant then sends an EAP-start message. The AP relies on an EAP-request identity message to
obtain the supplicant's identity. The client's EAP-response packet containing the supplicant's identity is
forwarded to the AS.
The AS authenticates the supplicant and either responds by accepting or rejecting the supplicant.
Depending on the response from the AS, a positive authentication response will enable the port and
negative authentication response will result in the port remaining blocked.
Extensible Authentication Protocol (EAP) To address the shortcomings of WEP for authentication, the
industry is working toward solutions based on the 802.1x specification, which is based on the Internet
Engineering Task Force (IETF) EAP. EAP was designed with flexibility in mind, and it has been used as
the basis for many types of network authentication.
802.1x is based on EAP. EAP is formally specified in RFC 2284 and was initially developed for use with
the Point-to-Point Protocol (PPP). When PPP was first introduced, two protocols were available to
authenticate users, each of which required the use of a PPP protocol number. Authentication is not a onesize-
fits-all problem, and it was an advanced area of research at the time. Rather than burn up PPP
numbers for authentication protocols that might become obsolete, the IETF standardized EAP.[16]
IEEE 802.1x is not a single authentication method; rather, it utilizes EAP as its authentication framework.
This means that 802.1x-enabled switches and APs can support a wide variety of authentication methods,
including certificate-based authentication, smart cards, token cards, one-time passwords, and so on.
However, the 802.1x specification itself does not specify or mandate any authentication methods. Figure
4-15 illustrates an 802.1x protocol stack showing the use of a variety of EAP types.
Figure 4-15: 802.1x protocol stack
Since switches and APs act as a pass through for EAP, new authentication methods can be added
without upgrading the switch or AP, by adding software on the host and back-end AS.
Since IEEE 802.1x does not involve encapsulation (unlike Point-to-Point Protocol over Ethernet [PPPOE]
or VPN), it adds no per-packet overhead and can be implemented on existing switches and APs with no
performance impact. This means that IEEE 802.1x can scale from speeds of 11 Mbps (802.11) to 10+
Gbps and can be enabled on existing switches with a firmware upgrade without the need to buy new
hardware. On hosts, since IEEE 802.1x can be implemented in the NIC driver, support can be enabled by
obtaining updating drivers from the NIC vendor; you do not need to install a new operating system.
IEEE 802.1x integrates well with open standards for authentication, authorization, and accounting (AAA)
(including RADIUS and Lightweight Directory Access Protocol [LDAP]) so it fits in well with the existing
infrastructure for managing dial-up networks and VPNs. RADIUS servers (including Windows 2000 IAS)
that support EAP can be used to manage IEEE 802.1x-based network access.
These specifications describe how IEEE 802.1x works, and how it can be managed via RADIUS and
SNMP. Through RADIUS, IEEE 802.1x permits the management of authorization on a per-user basis.
Per-user services include filtering (layer 2 or layer 3), tunneling, dynamic virtual LANs (VLANs), rate
limits, and so on.[17],[18],[19]
Supplicants for 802.1x/EAP The supplicant for 802.1x/EAP is included in Windows XP. In November
2002, Microsoft not only released a Windows 2000 client,[20] but also pledged future client support for the
older Windows 98, ME, and NT 4 releases. It is planned to be developed under Linux, FreeBSD, and
OpenBSD with the Open1X project.[21] Apple has not implemented an 802.1x/EAP supplicant at the time
of this writing.
802.1x/EAP Authenticators Many commercial APs such as Cisco, Lucent/Orinoco/Agere, and Enterasys
feature 802.1x authentication support. Support for homebrew authenticators is provided with the Open1X
project.
Remote Access Dial-In User Service (RADIUS) RADIUS[22] is currently the de facto standard for remote
authentication. It is a widely deployed protocol for network access AAA in both new and legacy systems.
Although a few security and transport issues are associated with it, it is very likely that RADIUS will
continue to be widely used for many years to come.[23],[24],[25] Eventually, RADIUS may be replaced by a
new protocol called DIAMETER. RADIUS is simple, efficient, and easy to implement—making it possible
for RADIUS to fit into even the most inexpensive embedded devices.
The security issues revolve around the shallowness of the protocol and poor implementation of the
specification. The protocol lacks confidentiality, authentication of client messages, and protection against
a replay attack (integrity). The shared secret scheme does not allow for enough entropy in the keys and it
seems to be open to offline dictionary attacks. RADIUS needs to be secured with an external protocol like
IPSec.
The issues with transport are most relevant for accounting, in situations where services are billed
according to usage. RADIUS runs on the User Datagram Protocol (UDP) and has no defined
retransmission or accounting record retention policy, and does not support application-layer
acknowledgments or error messages. Lost packets can mean revenue loss. This makes RADIUS
accounting unreliable for usage-based billing services, particularly in interdomain usage (such as
roaming) where substantial packet loss can occur over the Internet.
Two specifications make up the RADIUS protocol suite: authentication and accounting. The
authentication portion can be used to determine if a user can gain access to the network. The
authentication can be done locally or by proxy to another RADIUS server.
If you're a wireless Internet service provider (WISP), and you're reselling access on your APs to roaming
parties, you can recognize these roamers by a suffix on their username. The RADIUS server should have
a policy implemented as to who, when, and where to proxy to, and the extent to which you allow the
remote server's answer to define the response that is sent to the roamer.
The remote server may be chosen based on a part of the username, the network specified in the
username, or any other piece of information that's available about a request. You can also get the IP
addresses and shared secrets for your remote server from any external source you like, so that you can
easily maintain these destinations.
A couple of open-source implementations of RADIUS are available from www.freeradius.org/ and www.
xs4all.nl/~evbergen/openradius/index.html. FreeRADIUS is available for a wide range of platforms,
including Linux, FreeBSD, OpenBSD, OSF/Unix, and Solaris. Open-RADIUS is a RADIUS server that
can be compiled to run on many variations of Unix.
EAP-MD5 EAP-MD5, or the Challenge Handshake Authentication Protocol (CHAP),[26] represents a kind
of base-level EAP support among 802.1x devices. It is the least secure version of EAP because it uses
usernames and passwords for authentication that are easily socialized. It is also vulnerable to dictionary
attacks. In addition, EAP-MD5 does not support dynamic WEP keys, which is a critical liability.
LEAP
Cisco was one of the first vendors to market with its proprietary LEAP.[27] LEAP works only with Cisco
client 802.11 cards, RADIUS servers, and Cisco APs. LEAP is vulnerable to man-in-the-middle dictionary
attacks.
EAP-TLS EAP-TLS is an open standard that is supported by many vendors.[28] It uses Public Key
Infrastructure (PKI) and thus is very secure by using asymmetric public and private keys. EAP-TLS is
supported natively in Windows XP and by Windows 2000 severs. The only burden is that a PKI must be
set up because every device needs an x.509 certificate. However, once EAP-TLS is set up, it is virtually
transparent to the user.
EAP-TTLS EAP-TTLS and EAP-TLS are similar in that both use TLS (the successor to Secure Sockets
Layer [SSL]) as the underlying strong cryptography. However, EAP-TTLS differs in that only the RADIUS
servers, not the users, are required to have certificates. The user is authenticated to the network using
ordinary password-based credentials, whose use is made proof against active and passive attacks by
enclosing it in the TLS security wrapper.
EAP-SIM EAP-SIM is an EAP method designed by Nokia that allows hardware authentication to a SIM
chip. A SIM is a secure processor about the size of a small postage stamp. SIMs are currently used in
Global System for Mobile Communications (GSM) mobile phones to authenticate a user on a mobile
network. After clicking connect and optionally entering a personal identification number (PIN), the system
authenticates with the network and then connects to the Internet. The beauty of a SIM chip is that it
makes cloning authentication secrets very difficult. It is likely that many GSM carriers like T-Mobile and
Sonera will implement EAP-SIM to secure their public WLAN offering.
PEAP Protected EAP (PEAP) is another Cisco-developed protocol. Although EAP was originally created
for use with PPP, it has since been adopted for use with IEEE 802.1x network port authentication. Since
its deployment, a number of weaknesses in EAP have become apparent. These include a lack of
protection of the user identity or the EAP negotiation, no standardized mechanism for key exchange, no
built-in support for fragmentation and reassembly, and a lack of support for fast reconnect.
By wrapping the EAP protocol within TLS, PEAP addresses these deficiencies.[29] Any EAP method
running within PEAP is provided with built-in support for key exchange, session resumption and
fragmentation, and reassembly. PEAP provides the ability to seamlessly roam between APs. In the near
future, PEAP will support the same EAP types that EAP supports.
The Downfall of 802.1x/EAP The downfall of 801.1x/EAP is a lack of supplicants. Although an 802.1x
supplicant is supplied in Windows XP, and a patch is available for Windows 2000, no supplicants are
available for Windows 98, ME, CE, NT-4, Linux and its variants, and Apple 9 and X operating systems. A
Linux open project called open1x has been started at http://www.open1x.org/links.html. Since Apple X is
essentially based on Unix, once the open 1x implementation works, it will probably be ported over. The
bottom line is that unless supplicants are available that are compatible with the operating systems that
are being used, 802.1x/EAP won't be able to provide a complete solution.
VPNs
A VPN enables a specific group of users to access private network data and resources securely over the
Internet or other networks. VPNs are characterized by the concurrent use of tunneling, encryption,
authentication, and access control over a public network.
VPNs create virtual point-to-point connections using a technique called tunneling. As the name suggests,
tunneling acts like a pipe that bores through a network cloud to connect two points. Typically started by a
remote user, the tunneling process encapsulates data and encrypts it into standard TCP/IP packets,
which can then securely travel across the Internet to a VPN server on the other side where they are
decrypted and de-encapsulated onto the private LAN network.
Two basic VPN types are available:
l Remote access VPNs These securely connect remote users, such as mobile users and
telecommuters, to the enterprise. This type of VPN can be used by 802.11 users to initiate a session
back to their corporate LAN—for example, salespeople equipped with laptops and telecommuters
who would like to connect intermittently from diverse locations such as hotels, airports, convention
centers, and coffee shops. The key concerns are encryption and authentication. Performance and
bandwidth can also be sacrificed because the connection is broadband.
l LAN-to-LAN VPNs These securely connect remote and branch offices to the enterprise (intranet
VPNs). They also securely connect third parties, such as customers, suppliers, and business
partners, to the enterprise (extranet VPNs). Intranet or extranet VPNs can be used to secure wireless
point-to-point links. For example, a wireless back haul may connect a hot spot back to a central
location. This type of VPN needs to be encrypted and authenticated as well as meet strict
performance and bandwidth requirements since this kind of connection carries network traffic.
How VPN Works for 802.11 To support 802.11 WLANs, VPN client software application is deployed on all
machines that will use the WLAN, and a VPN gateway is introduced into the network between the AP and
the WLAN segment, as shown in Figure 4-16.
Figure 4-16: A WLAN with VPN
An encrypted VPN tunnel is built from the laptop through the wireless gateway and terminated at the VPN
gateway in order to gain access to the wired LAN through the wireless AP. All traffic passing through the
AP must go through the VPN gateway before entering the LAN. The cleartext data on the other side of
the secure tunnel can then continue onto its destination inside the local network. The VPN tunnel
provides authentication, data confidentiality, and data integrity. Thus, other encryption mechanisms such
as WEP are no longer needed.
A VPN solution also enables mobile workers to access their network from a remote location where
security may or may not be provided, as shown in Figure 4-17.
Figure 4-17: A WLAN with VPN using remote network access
The secure tunnel extends from the client's computer, through the Internet, and through the firewall/VPN
gateway to the VPN server. From the VPN server, the data continues to its destination inside the
corporate network.
Vulnerabilities of VPNs Although VPNs are touted as a secure solution for WLANs, VPNs using one-way
authentication are still vulnerable to exploitation such as man-in-the-middle attacks.
The deployment of WLANs in large organizations can create a nightmare of distributing and maintaining
client software to all clients. Almost all VPN solutions shipping today are proprietary (not IETF standard)
in some form or another and are generally not interoperable. Because of this fact, not all devices may
have client software available for any one VPN supplier. Also, it is often the case that once a VPN is
installed, a different VPN won't operate on the same machine. Thus, VPNs are impractical for securing a
public access WLAN.
It is also important to note that many of the proprietary security extensions may have security flaws due
to the lack of cryptographic rigor applied to them. Despite these vulnerabilities, encryption, authentication,
and integrity remain essential elements of WLAN security.[30]
VPN Standards Many protocols have been written for use with VPNs. These protocols attempt to close
some of the security holes inherent in VPNs. These protocols continue to compete with each other for
acceptance in the industry and are not compatible with each other.
IPSec IPSec VPNs have nearly become accepted as the de facto standard for securing IP data
transmission over shared public data networks since VPN software has been developed for a wide
variety of clients. It addresses authentication, data confidentiality, integrity, and key management, in
addition to tunneling.
Basically, IPSec encapsulates a packet by wrapping another packet around it. It then encrypts the entire
packet. This encrypted stream of traffic forms a secure tunnel across an otherwise unsecured network.
Interoperability issues still exist between different vendors' implementations.
PPTP PPTP is a protocol specification developed by several companies. Nearly all flavors of Windows
include built-in support for the protocol. PPTP was the dominant VPN before IPSec was deployed. PPTP
tunnels data, encrypts user data, and authenticates users.
PPTP is a tunneling protocol that provides remote users encrypted, multiprotocol access to a corporate
network over the Internet. PPTP uses generic routing encapsulation (GRE). PPTP wraps IP packets in
GRE packets before sending them down the tunnel. Network layer protocols, such as Internetwork
Packet Exchange (IPX) and NetBIOS Enhanced User Interface (NetBEUI), are encapsulated by the
PPTP protocol for transport over the Internet.
The initial releases of PPTP for Windows by Microsoft contained security features that some experts
claimed were too weak for serious use. However, Microsoft continues to improve its PPTP support.
L2TP L2TP was developed by Cisco. L2TP supports non-TCP/IP clients and protocols (such as frame
relay, Asynchronous Transfer Mode [ATM], and Synchronous Optical Network [SONET]), but fails to
define any encryption standard. Although L2TP is compatible with most network protocols, it is not widely
deployed, but is common in certain telco and ISP networks.
L2TP over IPSec L2TP over IPSec offers tunneling, user authentication, mutual computer authentication,
encryption, data authentication, and data integrity. L2TP offers multiprotocol support.
SSL SSL, working only with TCP/IP protocols, is the primary protocol for secure connections from web
browsers to web servers, usually for secure credit card connections or sensitive data. SSL requires a
valid site certificate issued from an authorized certificate authority. SSL provides tunneling, data
encryption, mutual authentication, integrity, and nonrepudiation.
SOCKS Network Security Protocol SOCKS is a VPN protocol that operates on layer 5, whereas most
others operate at layer 2 or 3. SOCKS version 5 is a circuit-level proxy protocol that was originally
designed to facilitate authenticated firewall traversal. Functioning at a higher level means that SOCKS
only operates with certain applications. SOCKS v5 supports a broad range of authentication, encryption,
tunneling, and key management schemes. It is generally considered to be a market failure.
IP Addresses—Network Address Translation (NAT)/Port Address Translation (PAT) Many VPNs require
fully routable/ public IP addresses and no port blocking on any ports except incoming port 80 and port
139 (VPNs do not use these ports). This is because the VPNs cannot tolerate NAT or PAT. However,
NAT/PAT is necessary in order to provide network security, prevent subscribers from running host
servers on their LAN, and preserve valuable IP address space.
A growing number of VPN clients support emerging standards for UDP encapsulation to push IPSec
through NAT/PAT. PPTP often passes through NAT/PAT without trouble, but L2TP over IPSec also
requires encapsulation.