The lying Network Access Server (NAS) problem comes from weakness in IETF Authentication Authorization and Accounting (AAA) standards. Malicious operators can trick users to connect to access networks against their will. For example, you think you are connected to network A but actually you are connected to network B. This article analysis this issue in detail an provide some guielines on how to prevent from being a victim of a lying NAS.

[rfc3748]

From [draft-clancy-emu-chbind-04]

The following are a couple example attacks possible by presenting false network information to clients.

Enterprise Network: A corporate network may have multiple virtual LANs (VLANs) running throughout their campus network, and have IEEE 802.11 access points connected to each VLAN. Assume one VLAN connects users to the firewalled corporate network, while the other connects users to a public guest network. The corporate network is assumed to be free of adversarial elements, while the guest network is assumed to possibly have malicious elements. Access Points on both VLANs are serviced by the same EAP server, but broadcast different SSIDs to differentiate. A compromised access point connected to the guest network could advertise the SSID of the corporate network in an effort to lure clients to connect to a network with a false sense of security regarding their traffic.

Service Provider Network: An EAP-enabled mobile phone provider operating along a geo-political boundary could boost their cell towers' transmission power and advertise the network identity of the neighboring country's indigenous provider. This would cause unknowing handsets to associate with an unintended operator, and consequently be subject to high roaming fees without realizing they had roamed off their home provider's network. This scenario can be considered as “lying provider” problem, because here the provider tampers with the transmission power and then configures its NAS to broadcast another network's identity. For the purpose of channel bindings as defined in this draft, it does not matter which local entity (or entities) is “lying” in a service provider network (local NAS, local authentication server and/or local proxies), because the only information received from the visited network that is verified by channel bindings is the information the home authentication server received from the last hop in the communication chain. In other words, channel bindings enable the detection of inconsistencies in the information from a visited network, but cannot determine which entity is lying. Naturally, channel bindings for EAP methods can only verify the endpoints and, if desirable, intermediate hops need to be protected by the employed AAA protocol.

In the second part of this article, we will see how users and operators can protect them selves against the lying NAS problem.

Labels: wireless, security