MAC Address Hijacking Problem doc.: IEEE 802.11-02/141r0 February 2002 MAC Address Hijacking Problem Jon Edney, Henry Haverinen, J-P Honkanen, Pekko Orava J. Edney, H. Haverinen, J-P Honkanen, P. Orava ,Nokia

February 2002 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

MAC Address Hijacking Attack February 2002 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

Problem MAC address is not included in the authentication process February 2002 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

MAC Address Checks at AAA Server? February 2002 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

Local EAP identity/MAC Address Binding Checks? February 2002 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

February 2002 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

How to Check if an Address is in Use? February 2002 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