RADIUS Server Application Blog

This RADIUS server application blog is about RADIUS servers in general and Interlink's RAD-Series RADIUS Server specifically. Our goal here is to discuss how different RADIUS server applications can be extended to build unique, differentiated offerings for Carriers and ISPs.

Saturday, December 8, 2007

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.

Labels: , , , , , , , , ,

Tuesday, October 30, 2007

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.

Labels: , , , , , , , , ,

Tuesday, October 16, 2007

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.

Labels: , , , , , ,