web analytics

Security vulnerabilities in tunneled EAP methods

As authentication protocols evolved over time, weaker ones have either been replaced or modified to meet the increasing security needs in new environments. The development of secure tunneling techniques like TLS and IPSEC have generated a lot of interest in securing legacy or weaker authentication protocols using tunnels.

In the context of network access control, major vendors and the IETF have developed number of protocols in the intent to leverage TLS tunneling to achieve better security in access networks. These protocols include EAP TTLSv0 (rfc5281), Microsoft Windows XP SP1 PEAPv0 and Cisco PEAPv1.

It has been discovered that the majority of these protocols are vulnerable to man-in-the-middle attacks that would allow a malicious entity to infiltrate the network (1). This security vulnerability is still marked as an open issue to be solved.

This article provides detailed overview and resources to better understand the man-in-the-middle vulnerability of tunneled EAP methods.

Tunneled EAP authentication methods

During the first phase of a tunneled EAP authentication method, the network client verifies the identity of the RARIUS server by validating the server's TLS signature. The client and server will both derive a symmetric key to protect the second phase of the EAP authentication. The goal of the second phase is to validate the identity of the network client using what is called an 'Inner method'.

Typically a legacy password based method is used in the second phase. Even methods know to have security vulnerabilities can be used as inner methods because the security association derived from the initial TLS authentication will protect message exchanges that take place during the second phase.

Man-in-the-middle attacks on tunneled EAP authentication methods

As described by Nokia researchers in (1), this mode of operation can allow a man-in-the-middle to authenticate to the server as legitimate client by posing as an authenticator to a legitimate client using a non-tunneled protocol. When the same proof of credentials can be used in both authentications, the attacker merely shuttles the credential proof between them. PEAPv0, EAP-TTLSv0, and several other TLS tunneled methods are vulnerable to such an attack.

The active attack by a Man-in-the-Middle (MitM) proceeds as follows (1):

  1. MitM waits for a legitimate device to enter an untunneled legacy remote authentication protocol and captures the initial message sent by the legitimate client.
  2. MitM initiates a tunneled authentication protocol with an authentication agent
  3. After the tunnel is set up between MitM and the authentication agent, the MitM starts forwarding legitimate client's authentication protocol messages through the tunnel.
  4. MitM unwraps the legacy authentication protocol messages received through the tunnel from the authentication agent and forwards them to the legitimate client.
  5. After the remote authentication ended successfully, MitM derives the session keys from the same keys it is using for the tunnel.

The IETF EAP working group has recognized the problem of Man-in-the-middle attacks on tunneled EAP authentication methods. It is now marked it as an open issue to be solved (3) (4).

In which case the MitM vulnerability becomes a real risk

As most security vulnerabilities, a set of conditions must be met before the vulnerability can be exploited by malicious entities. In the case of MitM attacks on tunneled EAP methods, the vulnerability can be exploited in deployments where the legacy authentication protocol is used in another environment (not necessarily EAP authentication) without any tunneling, or without any encapsulation.

For example, network providers that provide UMTS and Wifi services would be compelled by using EAP-TTLS/AKA for authenticating wifi clients since the same AKA credentials used for UMTS can be leveraged. However, this puts the Wifi network at risk and makes it vulnerable to the MitM attack described above.

Another example where the MitM vulnerability becomes a risk is when using PEAP/MSCHAPv2 for wireless authentication and MSCHAPv2 for securing PPTP VPN connections.


You could leave a comment if you were logged in.