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.