1. Partial Proposal to TGw - AMID
Sept 2005
doc.: IEEE /0901r1
Sept 2005
Partial Proposal to TGw - AMID
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Jon Edney, Nokia
Jon Edney, Nokia

2. Sept 2005
doc.: IEEE /0901r1
Sept 2005
Abstract
This submission describes the concept of “Association MAC Identifier” (AMID) which can be used to avoid deadlock conditions due to loss of key material in management protections.
Jon Edney, Nokia
Jon Edney, Nokia

3. MAC Addresses The MAC Address serves two purposes:
Sept 2005
MAC Addresses
The MAC Address serves two purposes:
It uniquely identifies the interface “in the entire world”
It is used as a local identifier to distinguish between devices in the layer 2 network.
We contend that these are different requirements that are connected only because of history not because of purpose
Jon Edney, Nokia

4. Distinguisher vs. Identity
Sept 2005
Distinguisher vs. Identity
For use as a “network distinguisher”, MAC address only needs to be unique with the local layer 2 network - not globally!
“Identity” should be based on the credentials of the user - that can be properly authenticated. We contend that such credentials should not be overloaded with the network identifier.
Unique MAC address can serve both roles (as now) but has limitations
Jon Edney, Nokia

5. Limitation of static MAC address
Sept 2005
Limitation of static MAC address
A device can only make a single connection through a physical interface.
This is an arbitrary constraint imposed due to history
There is no reason why a device couldn’t support multiple instances on the network through the same physical connection (other than the MAC address constraint)
Jon Edney, Nokia

6. Why is this relevant to TGw?
Sept 2005
Why is this relevant to TGw?
A major reason that TGi did not include management protection was because of the “lockout problem” when state is lost.
The problem exists because the MAC Address becomes unusable for a period if the key state is lost.
If the STA is not limited to a single MAC address there is no problem
Jon Edney, Nokia

7. Sept 2005
Therefore we propose:
Within the local BSS, the STA is not required to use its MAC address as distinguisher.
An arbitrary MAC address is created each time a new association is attempted.
We call the arbitrary address “Association MAC Identifier” (AMID)
AMID can be a random value* (or STA could choose to use its actual MAC address)
If STA loses state it can reconnect using new AMID value. Old session will time out
*with local administration bit set
Jon Edney, Nokia

8. Basic Concept - summary
Sept 2005
Basic Concept - summary
The STA does not use its real MAC address when communicating to the AP
Instead it uses an arbitrary MAC Address called “Association MAC ID” (AMID)
A different value can be chosen each time the station connects
The real MAC address is sent confidentially to the AP during 4- way handshake
Jon Edney, Nokia

9. Overall concept STA STA AP MAC DS
Sept 2005
Overall concept
Real MAC address is used on DS and layers above the STA MAC
AMID is used only for frames across the wireless link
All management frames use session AMID but the real MAC address is inserted at UNITDATA SAP
REAL
MAC
REAL
MAC
UNITDATA SAP
STA
MAC
STA AP
AMID used here DS
LLC layer
802.11
MAC/
encryption
Jon Edney, Nokia

10. Solving the lockout problem
Sept 2005
Solving the lockout problem
Scenario:
STA connects using real MAC address and has keys for disassociate
STA loses state (e.g. due to unexpected reboot)
STA cannot now re-connect because AP requires authenticated dissassociate first.
Solution:
Using a new AMID value, STA can initiate a new connection at any time. It just repeats the first time connect procedure using the new AMID
Previous session will time out and be discarded
Jon Edney, Nokia

11. Acquiring the AMID Station selects random MAC address for AMID
Sept 2005
Acquiring the AMID
Station selects random MAC address for AMID
Station sends MAC Auth frame using AMID
If AMID is unique at AP, it sends “success” message
If AMID is in use AP sends “fail” message
AMID is assigned until authenticated de-auth message (or agreed time limit)
Jon Edney, Nokia

12. Implementation considerations
Sept 2005
Implementation considerations
Very simple to implement because AMID is used in all time critical processing - change is transparent to most of the STA implementation.
AMID / Real Mac Address substitution only occurs on MSDUs
STA can always choose to use Real MAC address instead of AMID based on policy
AP must advertise AMID support. Thus operator can “turn it off” if needed for diagnostics.
Jon Edney, Nokia

13. Relation to TGr Mechanism
Sept 2005
Relation to TGr Mechanism
Temporal key handshake occurs partly before and partly during association
The handshake occurring before association could be over the DS or over the air.
Implications:
STA must acquire AMID from new AP before starting handshake (i.e. do the open MAC auth first)
TGr broker function must be aware of AMID
Jon Edney, Nokia

14. Small change to TGr supports AMID
Sept 2005
Small change to TGr supports AMID
TGr will use action frame to carry “over the DS” communication
Action frame goes from STA to broker (usually current AP) which forwards to target AP
Action frame contains source MAC address of station
Need to also include AMID in action frame - the target AP must know value of AMID since STA will use AMID to associate! State must be established using AMID.
For non TGw operation AMID field = source MAC
No other change needed to TGr
Jon Edney, Nokia

15. Sept 2005
Probing
Probe requests are sent using a well known fixed source MAC address
Response is broadcast
Jon Edney, Nokia

16. Summary STA STA AP MAC DS
Sept 2005
doc.: IEEE /0901r1
Sept 2005
Summary
Use of AMID removes limitations of single fixed MAC address
Use of AMID solves key-loss lockout problem
Use of AMID is transparent outside the BSS
Low additional implementation overheads
REAL
MAC
REAL
MAC
UNITDATA SAP
STA
MAC
STA AP
AMID used here DS
LLC layer
802.11
MAC/
encryption
Jon Edney, Nokia
Jon Edney, Nokia