MAC Address Hijacking Problem

1. MAC Address Hijacking Problem Jon Edney, Henry Haverinen, J-P Honkanen, Pekko Orava J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

2. Introduction • This presentation describes a security problem related to MAC address “ownership” and MAC address hijacking attacks • Solution alternatives are also discussed J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

3. MAC Address Hijacking Attack • Good guy is connected to the WLAN after authentication and initiates a file transfer from a server • Bad guy wants to intercept the transfer and associates to another (local) AP using good guy’s MAC address • Bad guy does full authentication using his own (valid) credentials. He will be accepted by the second AP and then the MAC frames that were destined to the good guy will be sent to the bad guy instead • Good guy’s transfer will be successfully intercepted • In this scenario the second AP treats the new association as if the old station did a slow roam • This situation could occur in a public hot spot for example J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

4. Problem • MAC address is not included in the authentication process • No authorization to use a given MAC address is required • How could a station prove it owns its MAC address in the first place? J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

5. MAC Address Checks at AAA Server? • Any MAC address privacy solution will prevent transmitting the station’s fixed MAC address to AAA server in the Calling-Station-Id attribute • AP cannot learn the fixed MAC address securely before authentication and key distribution have been completed • We cannot require users to register their MAC addresses with the server • Impractical, unfriendly to the user • Won’t work if the AAA server is a proxy server to another type of authorization infra (e.g. GSM roaming or certificate roaming) • Independent backend AAA servers are used on shared public networks • A server cannot know if a given MAC address has been bound to some credentials in another server => It is infeasible to perform MAC address checks in the AAA server J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

6. Local EAP identity/MAC Address Binding Checks? • EAP Identity – MAC address mapping is a “many to many” relationship • In PEAP or TTLS, the actual identity is not shown to AAA client. A shared anonymous identity may be used (such as “anonymous@isp.com”) • EAP/SRP and EAP/SIM use pseudonym identities that change on each authentication exchange => The local WLAN network cannot guarantee MAC address “ownership” by binding it to an EAP identity J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

7. Proposed Solution • MAC address is owned in the local ESS (subnet) by whoever uses it first • If MAC address is not in use in the ESS, then anyone can start using it • If MAC address is in use, then all associations, reassociations and disassociations need to be protected with MSK • If station can prove it knows the MSK, then the station is authorized to use the MAC address • Knowledge of MSK is required even with full authentication • EAP identity is not checked – station can use any EAP identity J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

8. How to Check if an Address is in Use? • When a station tries to associate with a ”new” MAC address, the AP needs to verify that the MAC address is not in use • A possible approach: • AP unicasts a query to the proposed MAC address or broadcasts a query to all APs in the subnet • If the address is in use, then the “old” AP (in which the address is associated) must respond with a reject message J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia