On Wireless Networks
In Chapter 1, "Technology Overview," you learned the basics of the 802.1X. As a refresher, 802.1x is a standard that defines the encapsulation methodologies for the transport of the Extensible Authentication Protocol (EAP) protocol.
NOTE EAP was originally defined in RFC 2284, which is now obsolete due to RFC 3748.
The 802.1X standard allows you to enforce access control when wired and wireless devices attempt to access the network. Figure 8-5 illustrates the main components of 802.1x.
Figure 8-5 802.1x in Wireless Networks
Wireless Client Identity Store
with Supplicant Authentication Server (Mic,r0S.Oft AC™ Directory'
Figure 8-5 802.1x in Wireless Networks
Wireless Client Identity Store
with Supplicant Authentication Server (Mic,r0S.Oft AC™ Directory'
The following are the main components of 802.1x illustrated in Figure 8-5:
• Supplicant: Software running on the client workstation
• Authenticator: The wireless access point
• Authentication Server: RADIUS server such as the Cisco Secure Access Control Server (ACS)
• External Database: External database such as the Microsoft Active Directory, Lightweight Directory Access Protocol (LDAP), or any Open Database Connectivity (ODBC) repository.
NOTE The Cisco comprehensive identity-based solution, which is based on 802.1x, is referred to as Identity Based Networking Services (IBNS).
The basic 802.1x authentication negotiation scheme is illustrated in Figure 8-6.
Figure 8-6 802.1x Authentication Negotiation Basics
Wirless Client with Supplicant
Authenticator
Authentication Server
Figure 8-6 802.1x Authentication Negotiation Basics
Wirless Client with Supplicant
Authenticator
|
<— |
EAP-Identity-Request |
|
|
EAP-Identity-Response |
||
|
EAP-Auth Exchange |
||
|
<— |
EAP-Success/Failure |
|
|
EAPOL-Logoff |
||
|
-<— |
->- |
(EAP Method Dependent)
Auth Exchange with Auth Server Authentication Successful/Rejected
Policy Instructions
The following are the steps illustrated in Figure 8-6:
1 The client attempts to connect to the wireless network, and the wireless access point sends an EAP identity request to the client (supplicant).
2 The user enters his credentials, and the client machine sends the EAP identity reply to the wireless access point.
3 Depending on the EAP method, the client starts an authentication exchange to the authentication server. An EAP tunnel passes directly to the authentication server.
4 The authentication server accepts or rejects the user and sends further information/ instructions based on the authentication and authorization of the user.
At the end of the session, the client sends an EAPOL Logout message.
The different types of EAP methods are categorized as follows:
• Challenge/response based
• Cryptographic based
• Tunneling methods
• Generic token and one-time-passwords
The challenge-response-based EAP methods are the following:
• EAP with Message Digest 5: Uses MD5 hashing for authentication exchange
• Cisco LEAP: Authentication based on usernames and passwords
• EAP using the Microsoft Challenge Handshake Authentication Protocol Version 2 (MSCHAPv2)
RADIUS
The cryptographic-based EAP method is as follows:
• EAP over Transport Layer Security (EAP-TLS): Uses x.509 digital certificates and TLS for authentication
The most common EAP tunneling methods are as follows:
• EAP Tunneling Transport Layer Security (EAP-TTLS)
• EAP Flexible Authentication via Secure Tunneling (EAP-FAST): Designed not to require certificates
The EAP Generic Token Card (EAP-GTC) is an EAP method used for generic token cards and one-time passwords.
NOTE EAP-GTC is defined in RFC 3748. It does not protect the authentication data in any way.
The following sections describe each EAP method.
EAP with MD5
When you configure EAP-MD5, both the client and the authentication server must have a shared secret established out-of-band. This shared secret is typically a password associated with an identity/username. Figure 8-7 illustrates the primary steps within the EAP-MD5 authentication method.
Figure 8-7 EAP-MD5
Wireless Client with Supplicant Authentication Server
Figure 8-7 EAP-MD5
Wireless Client with Supplicant Authentication Server
|
m |
EAP-Identity-Request |
|
|
2 |
EAP-Identity-Response (HASH) |
|
|
Auth Exchange with Auth Server |
||
|
4 Allow or Deny |
Authentication Successful/Rejected |
|
|
nn |
Policy Instructions |
|
|
Access to the Network |
||
The following are the steps illustrated in Figure 8-7:
Step 1 A random challenge is sent to the supplicant from the wireless access point.
Step 2 The client sends its response containing the hash of the challenge created using the shared secret.
Step 3 The RADIUS authentication server verifies the hash and accepts or rejects the authentication.
Step 4 The wireless access point allows or disallows access based on the RADIUS authentication server decision.
Step 5 If the authentication is successful, the client gains access to the network.
Because EAP-MD5 is purely an authentication protocol, it does not provide encryption after the authentication process. Therefore, all the messages are transmitted in cleartext after authentication. In addition, because it is only a client authentication protocol, the server side is not authenticated. Subsequently, you cannot detect rogue wireless access points if you implement EAP-MD5. The use of mutual authentication provides a means of reducing the risk of users installing rogue access points within the infrastructure, because mutual authentication also requires the client to authenticate the server and, most definitely, rogue devices will not do this. Another way you can try to protect against rogue access points is to lock down your switches so that you can use only authorized MAC addresses on your wired network. This is explained later in this chapter.
TIP EAP-MD5 is vulnerable to dictionary and brute-force attacks when used with Ethernet and wireless.
Cisco LEAP
Cisco LEAP was initially developed to address the vulnerabilities that WEP showed. At that time, it was an alternative protocol that allowed you to deploy wireless networks without requiring a certificate infrastructure for clients by leveraging authentication mechanisms that were already available within the infrastructure. The following are some of the benefits presented by using Cisco LEAP:
• 802.1x EAPOL messages are used within Cisco LEAP.
• Server authentication is achievable.
• The client username and password are sent over MS-CHAP.
• RADIUS is used as the authentication server.
• LEAP provides mechanisms for deriving and distributing encryption keys. Many people are now migrating from Cisco LEAP to full 802.1x implementations.
EAP-TLS
EAP-TLS provides several features. For example, it supports mutual authentication providing an encrypted transport layer and the capability to change the keys dynamically. EAP-TLS requires the use of digital certificates. You need to keep this in mind when thinking about deploying EAP-TLS within your network.
NOTE EAP-TLS is defined in RFC 2246.
During the TLS handshake phase, the client and wireless device establish a session exchanging symmetric session keys used to encrypt the transport during the data transfer phase. TLS has two layers:
• Record layer: Includes information about fragmentation, MAC, and encryption
• Message layer: Includes four different types of messages The following are the four message types:
• Change cipher spec: This defines a change in the session context to be used by the record layer.
• Alert message: There are approximately 26 different alert message subtypes. (They include access denied, close notify, decryption failed, and certificate revoked.)
• Handshake protocol: During the handshake protocol, the client and the server exchange different hello messages; server authentication and key exchange messages; client authentication and key exchange messages; and the finalization message to close the session.
• Application data: This is the actual data that is transmitted over the TLS tunnel.
EAP-TLS does not use all parts of the TLS record protocol; however, it uses the TLS handshake for mutual authentication, for cipher suite negotiation, and for derivation of the session keys. EAP-TLS was initially designed for PPP connections; however, in wireless implementations, EAP-TLS is used as a strong and secure mechanism for mutual authentication and key establishment; then the native WEP mechanisms of the wireless device are used to encrypt the data.
PEAP
Many people refer to PEAP as the true EAP-TLS in wireless implementations. PEAP uses EAP-TLS functionality by securing the open exchanges, but it keeps things simple. For instance, PEAP requires only server-side certificates; however, it can still perform mutual authentication between the client and the server. It also uses TLS for the secure tunnel and lengthens the EAP-TLS exchange beyond the finished message to add client authentication and key exchange. One of the disadvantages of PEAP is that it is considered to be a chatty protocol. The PEAP protocol has two phases:
• Phase 1: Used to establish a secure tunnel using the EAP-TLS with server authentication
• Phase 2: Authenticates the client based on EAP methods, exchange of arbitrary information, and other PEAP-specific means using the information established during Phase 1
Many people use PEAP because it is simple to implement within a wireless infrastructure.
EAP Tunneled TLS Authentication Protocol (EAP-TTLS)
EAP-TTLS is basically the same as EAP-TLS; however, it extends the client authentication by the use of a method called tunneled authentication. With EAP-TTLS, the client does not need a digital certificate (only the authentication server requires one), thereby simplifying the client identity management.
NOTE EAP-TTLS enables you to also use legacy authentication methods such as password-based methodologies.
EAP-FAST
EAP-FAST was initially known as the Tunneled EAP (TEAP) and as LEAP Version 2. EAP-FAST is classified by many as the most comprehensive and secure EAP type suitable for wireless implementations. It addresses the risks of man-in-the-middle and dictionary attacks. In addition, EAP-FAST reduces the hardware requirements, making it a flexible deployment model and more attractive to many people.
EAP-FAST authentication does not require the use of a specific encryption type. Instead, the WLAN encryption type to be used is determined by the client wireless network interface card capabilities.
If the client devices do not support WPA2 or WPA, you can deploy 802.1X authentication with dynamic WEP keys, but, because of the well-known exploits against WEP keys, this WLAN encryption mechanism is not recommended. If you must support WEP-only clients, it is recommended that you employ a session-timeout interval which requires that the clients derive a new WEP key on a frequent interval.
TIP 30 minutes is the recommended session interval for typical WLAN data rates.
Cisco has a comprehensive list of frequently asked questions about EAP-FAST at
http://www.cisco.com/en/US/products/hw/wireless/ps4555/
products_qanda_item09186a00802030dc.shtml.
EAP-GTC
EAP-GTC enables you to use hardware token cards as one-time-passwords. An example of a hardware token card is the RSA SecurID solution.
NOTE For more information about RSA SecurlD, go to http://rsa.com.
You can use EAP-GTC inside the TLS tunnel created by PEAP. You can use this EAP method to implement a two-factor authentication solution to avoid common password compromises and combine it with your remote access VPN solution. For instance, a user can use the token card for both wireless and remote access VPN authentication. If you are just starting to deploy a WLAN, you must decide whether token deployment is cost effective. Many people justify the cost of token deployment by using this authentication mechanism with other network infrastructure authentication, such as remote access VPN.
In summary, the two EAP methods that most people implement today are EAP-FAST and PEAP. EAP-FAST provides more flexibility when deployed with 802.1x or NAC. EAP-FAST is easy to implement, and it is not Cisco proprietary. It supports Windows single-sign-on and provides support for login script operation with any user database such as Microsoft Active Directory, Lightweight Directory Access Protocol (LDAP), and one-time password (OTP). In addition, because EAP-FAST does not require certificates, you can configure it easily and distribute it for Cisco Aironet client devices with the Cisco Aironet Configuration Administration tool.
TIP It is recommended that you employ either WPA2 (AES-CCM) or WPA (TKIP) encryption, which are both dependent on the NIC card capabilities in the specific deployment.
Continue reading here: Configuring the Cisco Secure ACS Server for 8021x and Eapfast
Was this article helpful?
Readers' Questions
-
sharon18 days ago
- Reply
-
temshe kifle10 months ago
- Reply
-
hyiab alem10 months ago
- Reply