1. MAC Address Hijacking Problem
doc.: IEEE /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

2. 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

3. 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

4. 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

5. 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

6. 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
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. 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

8. 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