Selecting an EAP Method - RADIUS Server Implications

With this blog entry, we conclude our series on factors involved in choosing the best authentication method for a 802.1X applications by discussing RADIUS servers. Like the supplicant software discussed last month, the choice of a RADIUS server is critical because it is one of the endpoints engaging in the EAP authentication and must therefore have direct support for the chosen EAP method. The RADIUS server must also have support for the directory or database being used to store the user profiles and credentials.

Platform Flexibility

In the vast majority of cases, wireless networking is an added feature rather than a function designed into the enterprise’s original network. If wireless security is to be achieved, then a RADIUS server compatible with existing enterprise networks and meeting corporate requirements must be selected. Enterprises with established IT departments often have standards for servers. Any new server must run on the standard platform and operating system whether it is Unix, Linux, or Windows. Smaller enterprises cannot afford the IT expertise necessary to support multiple platforms. In some of these cases, a turnkey RADIUS appliance may be the best choice. The choice of the best EAP method should not be further complicated or limited by a RADIUS server lacking in flexibility and power.

Legacy RADIUS Servers

The existing network may already include legacy RADIUS servers used to authenticate dial-in access and wired access to systems. The reasonable options are to either replace the legacy server that can do both EAP and standard RADIUS authentication, or to add a new RADIUS server, which can interact with the legacy RADIUS server to authenticate wireless users. The option of adding a dedicated RADIUS server for wireless access would complicate user management by requiring its own user database.

If the first option is chosen, then the new RADIUS server must support the existing user repository, whether it is flat files, an LDAP directory, kerberos, or SecurID. More significantly, the RADIUS server must be able to distinguish between wired and wireless RADIUS authentication requests for the same user and handle them appropriately. Interlink Networks’ RAD-Series RADIUS Servers has the flexibility and power to configure both wireless and wired authentication for the same user groups. The server uses the contents of the access request to determine the protocol being used and which configuration should be applied.

If the second option is chosen, then the two RADIUS servers must work together. The legacy RADIUS server does not support EAP, but it has access to the user profiles. The wireless authentication server supports EAP, but does not have direct access to the user credentials. In this scenario, TTLS is the EAP method of choice. The wireless RADIUS server authenticates the network to the supplicant using a digital certificate and establishes a TLS tunnel through which a legacy protocol can be used to authenticate the supplicant to the network. The wireless RADIUS server terminates both the TLS tunnel and EAP. The user authentication using PAP, CHAP, or MS-CHAP is then forwarded to the legacy RADIUS server as a standard RADIUS request that it can handle.

Digital Certificate Support

If the enterprise already has a Public Key Infrastructure (PKI), then EAP-TLS is the EAP method that can satisfy those requirements. Other enterprises will find EAP-TLS less attractive because of the significant overhead of generating and managing user certificates. To adequately support EAP-TLS, the RADIUS server should support certificate revocation lists (CRL).

Password Hashes

For many authentication methods, passwords are the keys that open the gates of the network. As such, network administrators take additional security measures to protect passwords. They avoid protocols like PAP, which involve transmitting the password, and store a one-way hash of the password in the user’s profile instead of the password itself. Commonly used hashes include crypt on Unix systems, nthash on Windows systems, and SHA-1 or MD5 in LDAP directories. Because a one-way hash cannot be decrypted, some hashes will not be usable in protocols where the RADIUS server is authenticated by proving to the supplicant that it has the user’s password. In particular, Cisco LEAP and PEAP-MSCHAPv2 will only work if the password is stored in cleartext or an nthash.

If the password is already stored in a hash other than nthash, then the solution is to use one of the tunneled EAP methods like EAP-TTLS or PEAP. By creating a TLS encrypted tunnel, these methods make it secure to use an inner authentication protocol, which involves transmitting the user’s password from the supplicant to the RADIUS server. The RADIUS server then performs the appropriate hash operation on the password and compares the result to what is stored in the user’s profile. For EAP-TTLS, PAP will work as the inner authentication method and EAP-GTC will work as the inner authentication method for PEAP. CHAP and MS-CHAP will not work as inner authentication protocols because they involve a series of challenges instead of transmitting the user’s password inside of the tunnel. Mutual authentication means both ends must prove that they have the password.

Microsoft Active Directory Issues

Microsoft’s Active Directory Server (ADS) stores user passwords as an nthash. However, it takes user password security a step further in that it does not return any password hashes in response to an LDAP search. This does not necessarily restrict your options for EAP methods.

If the RADIUS server runs on a different machine from ADS, then the LDAP interface must be used and the same issues apply as were discussed for hashed passwords. In this case, either EAP-TTLS with PAP or PEAP-GTC should be chosen as the EAP method. Through the security of a TLS encrypted tunnel, they both provide a username and password, which can be authenticated by binding them to the ADS LDAP interface.

Conclusion

Through the course of this series of blog entries we have seen that the choice of an EAP method in wireless networking is essential in delivering both security and interoperability. Which EAP method is best for an enterprise can be determined by looking at its requirements for wireless station platforms, access points, and the network infrastructure. The choice of the right RADIUS server completes the security solution, provided that it is flexible and powerful enough to support the network’s platforms, databases, existing security systems, and desired EAP methods. Interlink Networks’ RAD-Series RADIUS Server supports the broadest range of platforms and EAP methods, making it possible to implement the strongest security with the greatest ease of use.

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.

Introduction: Selecting an 802.1X EAP Method

Wireless networking is a hot technology because of the flexibility and productivity it offers. It removes boundaries and barriers to communication, empowering an increasingly mobile society. Wireless networking also gained a lot of attention and concern because of the new security challenges that it introduced. Because of the broadcast nature of wireless networking, security must be expanded beyond the requirements of wired networks to include mutual authentication, distribution of session keys, and immunity to dictionary attacks to name a few. The industry has responded with a series of technologies such as EAP, WEP, WPA, and TKIP.

The common thread in these security developments for the RADIUS server using 802.1X technology is EAP - Extensible Authentication Protocol. EAP is a vehicle for meeting today’s wireless security requirements. As the name suggests, it is powerful because it is extensible. This is a two edged sword to the IT director wanting to implement wireless networks in his enterprise. On the one hand he has the assurance that EAP is a standard solution, will not soon become obsolete, and can be extended to meet future needs. On the other hand he is confronted with a complex array of EAP methods from which to choose, and still more methods being developed.

EAP methods are the authentication protocols being transported within the EAP framework over 802.1X between the supplicant (client) and the RADIUS server. There are advantages, disadvantages, and requirements for each of the various methods.

Given the wealth of choices, how is one to identify the best EAP method for a given enterprise? As is the case with any networking function, there are a number of pieces to the puzzle that must all fit together. A review of the relevant network components will help to clarify the EAP method decision and prevent the costly mistake of an incompatible or incomplete solution.

The key network components to consider when implementing wireless security are:

Wireless Station Supplicant Software (Clients)

The wireless station must have supplicant software to engage in the 802.1X/EAP authentication exchange with the RADIUS server. Some EAP methods are standard with some operating systems and others require the installation of additional client software.

Access Points

The access point is the gateway for wireless communication. It must support 802.1X and EAP at a minimum, but there may be other requirements. Some methods require additional support, which is not available from all vendors.

Data Stores

Ideally, the wireless security system should be integrated with existing and future network systems rather than creating redundant systems that are difficult to synchronize and maintain. Of particular concern is where and how the user credentials are stored. Many EAP methods have specific credential requirements that are not obvious to the uninformed.

Authentication Server (RADIUS Server)

As the authority to which you have entrusted the security of your wireless network, the RADIUS server (authentication server) must support the EAP method, have an interface to the user credential database, and support any vendor specific features of the access point.

Upcoming RADIUS server blog posts will address each of these factors in greater detail, highlighting the advantages and limitations for each EAP method. Armed with this knowledge, an informed decision can be made on how best to secure your wireless network with a RADIUS server.