In a past life I was responsible for a number of Windows Enterprise Networking technologies including the EAP implementation and was a contributor to EAP-TLS.
As a result when I saw the Heartbleed vulnerability announced I was painfully aware of what an attacker could do if they encountered a EAP-TLS implementation based on a vulnerable version of OpenSSL.
I have read a few articles this morning discussing the implications to those who use EAP-TLS and many of them get it wrong; the core issue being they don’t seem to understand the various actors in a EAP-TLS negotiation.
To understand how EAP works you need to understand the following terms:
Peer; this is the client to the wireless network. Be it your desktop, laptop or mobile phone (though EAPs use is not limited to these types of devices). Sometimes this will be called the supplicant.
Authenticator; this is your wireless router, when it comes to authenticator this entity delegates that responsibility to the authentication server (typically over RADIUS).
Authentication Server; this is the entity who is responsible for deciding if the peer can have access or not, it is also typically the EAP-Server but it can delegate this to another entity as in the case of complex wireless federation systems like.
EAP Server; this is the entity who actually implements the EAP protocol.
When a client connects to a router the router is configured to forward all requests to an Authentication Server. This results in a tunnel through the router to the authentication server.
In the most common case that authentication server implements the EAP protocol along with all of the various protocols (methods) that it supports.
In a Windows environment that server is called the Network Policy Server (NPS), CISCO’s is called Cisco Secure Access Control Server (ACS), Juniper’s is called Steel Belted Radius (SBR) and the two most common Open Source distributions are OpenRADIUS and FreeRadius both of which use OpenSSL ([1], [2]).
The reason I wrote this is most of these articles talking about CUPID do so in such a way that it suggests the wireless router itself is the issue; while this is technically possible because there are routers out that also contain the authentication server and EAP Server these are not commonly used – especially with a TLS based EAP method. The main reason for this is that this quickly doesn’t scale, one of the largest reasons being that environments mature enough to take on the management overhead of a TLS based solution also probably have to provide service to a space larger than a single access point could cover.
There is another class of wireless access solution that leverages a “wireless controller” that manages multiple radios for this very reason. These solutions also often have built in RADIUS and EAP servers (and in my experience they are based on one of the above OpenSource solutions) but again this capability doesn’t appear to be used often with TLS based EAP methods since organizations often already have existing authentication infrastructure (Active Directory and NPS for example) that they leverage instead.
Long story short your probably only at risk of this if your using one of the Open Source Radius servers but since some vendors just repackage this code there are deployment models where you may be exposed its just not super likely. Here is a quick decision tree to help you understand your exposure:
