RADIUS & 802.1X: Selecting an EAP Method - Supplicant Software

In this blog posting, we continue our discussion of EAP methods and the factors involved in finding the best authentication method for a wireless application. We have already identified the components that must interoperate to deliver secure wireless communication and we have discussed the access point requirements. Our next topic is the supplicant software, which runs on the wireless station such as the laptop, PDA, or phone. It is critical because it is one of the endpoints engaging in the EAP authentication (along with the RADIUS server at the other end) and must therefore have direct support for the chosen EAP method.

Supplicant Availability

Supplicant software is available from a number of sources, supporting a variety of EAP methods and operating systems. Most supplicants support EAP-MD5, EAP-TLS, and EAP-PEAP. However, not all vendors have implemented the same version of EAP-PEAP and each vendor has a different approach to managing user profiles. To minimize interoperability and management issues, settle on a single source of supplicant software that supports all of your required platforms, if at all possible. Please note that Interlink’s RADIUS server is standards-based and is designed to interoperate with all leading supplicants.

In some cases EAP supplicants are provided with the operating system. In particular, Windows XP includes support for both EAP-TLS and PEAP. Some organizations will prefer the simplicity of configuring a native supplicant to managing the installation and set up of third party software on all workstations.

User Profile Management

Supplicant software differs in its approach to managing the user profile ranging from those that are set up once and forgotten to those offering a great deal of flexibility and power. Some supplicant software includes a utility for configuring and managing multiple user profiles. This is useful for stations that will be used by multiple users or in multiple environments requiring different authentication methods. The user profiles are configured in advance and the appropriate profile selected as needed. At the other end of the spectrum are those supplicants that store the user identity and credentials at set up and then never require any intervention by the user. These are very easy to use but are more difficult to reconfigure. This becomes a problem if you want a policy of regularly changing passwords. It is also a security liability should the station ever become lost or stolen.

Identity Hiding

The tunneled EAP methods such as EAP-TTLS and EAP-PEAP support a concept called identity hiding. Authentication between the supplicant and authentication server takes place in two phases. In the first phase, the supplicant presents an outer user identity, in response to which the authentication server establishes an encrypted tunnel. This outer identity is often an anonymous user. The supplicant then presents the true user name as the inner identity used by the authentication method transported through the tunnel. Because the encrypted tunnel has its endpoints at the supplicant and the authentication server, the users true identity is hidden from the access point. Only the outer identity is visible to the access point. This feature may be desirable when the station is roaming on a foreign network but undesirable when managing users on the local network. Each supplicant has a different approach to identity hiding. Some supplicants offer only an anonymous outer identity, others use the username for both the inner and outer identities, and others make the outer identity configurable. Which approach is best depends on the need to make the user’s true identity either hidden or visible.

Conclusion

The choice of supplicant software is important. Because it must be distributed on all wireless stations, it may be difficult to change and manage once it is in the field. The EAP methods supported, platforms supported, ease of use, and flexibility can all be factors in making the right decision.

Interoperability between the supplicant and the RADIUS server is a critical factor being assured through testing by organizations like InteropNet Labs and the Wi-Fi Alliance. You can be assured of interoperability today by using an independent RADIUS server like Interlink’s RAD-Series RADIUS Server, which have been designed to conform to the latest industry standards and interoperate with leading supplicants and the widest range of EAP types in the industry. Interlink’s RADIUS Server supports both PEAP v0 promoted by Microsoft, and PEAP v1 implemented by Cisco, and are so flexible that you can mix and match supplicant software and EAP types – for example Alfa-Ariss’ TTLS supplicant and Cisco PEAP – and use them concurrently.

How the RADIUS server manages the user credentials and interacts with the supplicant will be continued in the next blog posting.

Comparing Certificate-Based RADIUS Authentication Methods: EAP-TLS, EAP-TTLS, and EAP-PEAP

In the latest series of blog postings, we started exploring 802.1X and EAP methods used to secure networks using a RADIUS server. In this posting, we'll compare the 3 different certificate-based authentication methods: EAP-TLS, EAP-TTLS, and EAP-PEAP.

EAP-TLS – Transport Layer Security

EAP TLS is one of the most commonly implemented EAP type for securing wireless LANs (Wi-Fi) through a RADIUS Server. In a Wi-Fi environment, the workstation must have a certificate that the RADIUS server can validate. Likewise, the RADIUS server must have a certificate that the workstation can validate. This is referred to mutual authentication. This is only true if both parties can validate the other’s certificate. This is typically done by having both certificates issued by one Certificate Authority (CA), and for each party to have the CA’s certificate.

Pros:

• Client is included in Windows Vista, XP, 2000 SP3
• EAP-TLS is resilient to man-in-the-middle attacks
• It provides explicit mutual authentication between the workstation and RADIUS server

Cons:

• Requires the complexity and expense of a CA to support the workstation and RADIUS server authentication
• Certificates are required on both the client and RADIUS server
• Requires certificate distribution and administration

EAP-TTLS – Tunneled Transport Layer Security

EAP-TTLS is an authentication protocol that uses TLS to provide a secure channel for traditional authentication methods like CHAP, MS-CHAP, MS-CHAP-V2, and MD5-Challenge. This reduces the certificate requirements and can leverage legacy RADIUS authentication methods.

Pros:

• Certificates are only required on the RADIUS server

Cons:

• Most clients are proprietary and cost between $25-$50
• Requires server certificate distribution and administration
• Requires the complexity and expense of a certificate authority for RADIUS server authentication

EAP-PEAP – Protected Extensible Authentication Protocol

EAP-PEAP is an authentication protocol backed by Microsoft, Cisco and RSA Security. PEAP extends TLS to carry an EAP exchange. Once the initial TLS exchange authenticates the RADIUS server to the workstation, any other EPA method can be used to authenticate the workstation to the RADIUS server. Thus, traditional EAP methods like MD5 or MS-CHAP can be used in conjunction with EAP-PEAP.

Pros:

• Server certificates are included in Windows XP, 2000

Cons:

• Requires server certificate distribution and administration
• Requires the complexity and expense of a certificate authority for RADIUS server authentication

Table 1 – Authentication Protocol Comparison

Issue	EAP-TLS	EAP-TTLS	EAP-PEAP
Client Certificates	Yes	Optional	Optional
RADIUS Server Certificates	Yes	Yes	Yes
Supported Authentication Database	Active Directory	Active Directory, NT Domains, Tokens, LDAP, SQL, RADIUS	Active Directory, NT Domains, Tokens1, LDAP1, SQL1,
Dynamic Key Exchange	Yes	Yes	Yes
Mutual Authentication	Yes	Yes	Yes
Client OS Support	Windows XP, 2000, Linux	Windows 98, ME, 2000, XP, CE	Windows XP
Access Point Support	Any that support 802.1x	Any that support 802.1x	Any that support 802.1x

¹ Cisco’s version of PEAP Only

Selecting an 802.1X EAP Method: Access Point Considerations

In the last RADIUS server blog posting, we embarked on the daunting task of securing access to a wireless network with a RADIUS server. This led us to 802.1X and the Extensible Authentication Protocol, EAP, which is at the heart of best practices for wireless network access management. Because of EAP’s extensible nature, we discussed that there are not only several network components to consider in securing the wireless network, but also many EAP Methods (protocols) from which to choose and configure in your clients and RADIUS server. In evaluating the currently available EAP Methods, we are examining factors involving each component of the wireless network. Because they provide the wireless connectivity, Access Points (APs) are the first and primary component that most enterprises evaluate. We will follow suit by looking at access point issues related to supporting wireless network access management using EAP.

802.1x Support

The most important AP feature necessary for wireless access management is support for 802.1x. This should be a requirement for enterprise wireless networks. One cannot take this feature for granted since it is generally not available on low cost consumer access points. 802.1x is the IEEE standard for Port Based Network Access Control. Included in this specification is the use of EAP for authentication. If an Access Point supports 802.1x, then it supports EAP.

WEP (Wired Equivalent Privacy) is another term frequently found on AP datasheets. While WEP based encryption is found often on APs using 802.1x, by itself it is not sufficient indication that EAP is supported. Many implementations authenticate by configuring static WEP keys. If the workstation can communicate by virtue of having the correct key, then it is authenticated. 802.1x was designed to overcome the numerous shortcomings of WEP key based authentication by authenticating user access through a RADIUS server. Additionally, WPA/TKIP has been developed to solve the problems of WEP’s poor encryption and data integrity.

Some Access Point datasheets will mention support for RADIUS. While RADIUS is used to transport EAP between the Access Point and the Authentication Server, it does not necessarily mean that the AP supports EAP. Some APs perform MAC address authentication with a RADIUS server. This form of authentication falls short of EAP’s ability to provide mutual authentication, authentication of the actual user, and session encryption keys with a RADIUS server.

Once it is determined that the AP supports 802.1x, then the next question is which EAP Methods are supported. The EAP authentication is conducted between the Supplicant (wireless device) and the RADIUS Server (Authentication Server). It is carried over EAPOL on the wireless side of the AP and over RADIUS on the network side of the AP. The AP only serves to relay the EAP packets, not to participate in the protocol. Therefore, any AP that supports 802.1x should be able to support all EAP methods. In practice, this is generally true. There have been exceptions found during interoperability tests, but these have been determined to be bugs that the AP vendors are expected to fix.

Proprietary EAP Methods

The one exception to the rule of thumb that all EAP Methods should be supported by all 802.1x APs is Cisco’s proprietary EAP-LEAP (Lightweight Extensible Authentication Protocol). It is only supported by APs, supplicants, and authentication servers that have licensed Cisco’s technology. LEAP makes use of Cisco’s vendor-specific attributes (VSAs) to distribute key material. The access point must support the Cisco VSAs and the LEAP algorithm for generating session keys from the key material. Because Cisco is a networking leader, LEAP has gained acceptance. Other vendor’s supplicants and authentication servers support LEAP – but if an enterprise wants to standardize on LEAP, then it must use Cisco APs.

Accounting Support

Although it is not a requirement for EAP, it should be noted that some access points do not support RADIUS accounting. This is an issue for ISPs and Wi-Fi hotspot venfors and less of an issue for enterprises that aren’t invoicing for wireless network access. However, all users might still want to implement audit trails and policies which require RADIUS accounting messages to mark the beginning and end of sessions.

Configuring EAP in the Access Point

Configuring EAP in an access point consists of four straightforward steps:

1. Enabling 802.1x, often by checking a box on a web form

2. Entering the authentication server’s IP address

3. Entering the authentication server’s port number (usually 1812)

4. Entering the secret shared with the authentication server

In conclusion, beyond the need to support 802.1x, the access point does not need to be a determining factor in which EAP Method to choose. The key is recognizing which access points support 802.1x. From there, enabling 802.1x and configuring communication with the authentication server is fairly straightforward. There is no need to configure a specific EAP method within the access point.

Choosing and configuring an EAP Method becomes more involved as we look at the supplicant and RADIUS server (authentication server in upcoming blog posts.