1. WiNOT Consortium: Proposal For TGu Protection Requirements Cluster
Month Year
doc.: IEEE yy/xxxxr0
January 2006
WiNOT Consortium: Proposal For TGu Protection Requirements Cluster
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
Stefano M. Faccin, Nokia
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
January 2006
WiNOT consortium
This presentation is made on behalf of the WiNOT (Wireless NetwOrking Technology), comprising:
Intel
Nokia
Siemens
Panasonic
STMicroeletronics
Cingular
BenQ
TeliaSonera
T-Mobile
Stefano M. Faccin, Nokia
John Doe, Some Company

3. January 2006
Protection Cluster
P2: Define functionality to prevent hijack of MAC addresses
P3: Provide functionality for MAC Address Anonymity
P5: Define the way in which the mechanism as defined in REQ R3N1 can be secured, so that an AN can not pretend to provide access to a SSPN
P6: Define how shared infrastructure architectures where the APs and network that connects them are shared by different operators will be supported.
Stefano M. Faccin, Nokia

4. Requirements Addressed
January 2006
Requirements Addressed
Proposal focuses mainly on P2 and P3
Input on P5 and P6 is provided
Stefano M. Faccin, Nokia

5. P3 What does anonymity mean? Two main aspects
January 2006
Requirement P3 P3
What does anonymity mean? Two main aspects
Anonymity during probing phase
Anonymity when associated/authenticated
Stefano M. Faccin, Nokia

6. Anonymity During Probing Phase
January 2006
Requirement P3
Anonymity During Probing Phase
Two possibilities:
use random MAC address to send Probe Request
use random multicast MAC address to generate Probe Request
In both cases in case of clash on the MAC address chosen by two STAs for probing, both get the answer
Stefano M. Faccin, Nokia

7. Anonymity when associated/authenticated
January 2006
Requirement P3
Anonymity when associated/authenticated
Why is Anonymity wanted now? What is new?
STAs are being built into cellular phones
Such phones are turned on all the time and will in most cases probe any network encountered
This is different scenario to laptops which are turned on when in office, home or known hotspot
Cell phones will encounter many unknown networks and do not want to leave a record of it’s identity at every one
Hence we want an anonymity mechanism
Stefano M. Faccin, Nokia

8. January 2006
Requirement P3
Overview
Today stations are required to use their actual MAC address for communication with the AP
We contend this is an unnecessary restriction that causes problems
enables device tracking from location to location
prevents stations initiating multiple connections (with multiple characteristics)
Stefano M. Faccin, Nokia

9. MAC Addresses The MAC Address serves two purposes:
January 2006
Requirement P3
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
Stefano M. Faccin, Nokia

10. Distinguisher vs Identity
January 2006
Requirement P3
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
Stefano M. Faccin, Nokia

11. Limitations of static MAC address
January 2006
Requirement P3
Limitations 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)
MAC address leaks information about identity
Stefano M. Faccin, Nokia

12. January 2006
Requirement P3
Therefore we propose:
Within the local network, the STA is not required to use its MAC address as identifier
At the ESS level the station uses an arbitrary MAC address: EMID “ESS MAC Identifier”
At the BSS level the station uses an arbitrary MAC address: AMID “AP MAC Identifier”
Stefano M. Faccin, Nokia

13. Basic Concept - Summary
January 2006
Requirement P3
Basic Concept - Summary
The STA does not use its real “MAC address” at all when communicating to the network
At the BSS level it uses a local value “AMID”
On the DS (intra-ESS) it uses a local value “EMID”
A different value is chosen each time the station connects
Stefano M. Faccin, Nokia

14. Overall concept STA STA AP MAC DS
January 2006
Requirement P3
Overall concept
EMID 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 EMID is inserted at UNITDATA SAP
EMID
EMID
UNITDATA SAP
STA
MAC
STA AP
AMID used here DS
LLC layer
802.11
MAC/
encryption
Stefano M. Faccin, Nokia

15. EMID Management EMID must be unique within ESS
January 2006
Requirement P3
EMID Management
EMID must be unique within ESS
Allocated by EMID server
APs SME talks to EMID server to acquire EMID
EMID
Server
BSS
BSS
BSS AP AP AP
Different AMID
for each BSS
Constant EMID in ESS
Stefano M. Faccin, Nokia

16. January 2006
Requirement P3
What is gained by this?
The AMID and EMID values are visible to uncontrolled parties. By using arbitrary values we obtain “anonymous” operation
The use of AMID allows the AP to reconnect to AP and roam without disturbing existing session (EMID remains fixed during roaming)
Use of EMID potentially allows multiple sessions from station to network
Stefano M. Faccin, Nokia

17. Allocation of AMID and EMID
January 2006
Requirement P3
Allocation of AMID and EMID
Station can be in one of the following states:
No AMID or EMID (starting state)
Have EMID but no AMID (transition state)
Have EMID and AMID (operating state)
Stefano M. Faccin, Nokia

18. Allocation steps Station constructs trial AMID based on random value
January 2006
Requirement P3
Allocation steps
Station constructs trial AMID based on random value
Station uses AMID for probe request and includes IE to indicate new AMID value
If STA has existing EMID it asserts value in the IE
If AMID is unique at AP, it responds with Probe response confirming AMID and sending new or existing EMID (AP checks validity of EMID)
If AMID is in use AP does not respond
EMID is confirmed later at 4-way handshake for RSN
AMID and EMID are assigned for lease period
Stefano M. Faccin, Nokia

19. January 2006
Requirement P3
Next steps
After acquiring a new EMID / AMID value pair station proceeds with connection steps using AMID
Confirm EMID by mixing into PTK
If successful, EMID is put into operation when data starts to flow
Stefano M. Faccin, Nokia

20. STA STA AP MAC Summary DS
January 2006
Requirement P3
Summary
Use of E/AMID removes limitations of single fixed MAC address
Use of E/AMID provides anonymity
Use of AMID is transparent outside the BSS
Low additional implementation overheads
STA determine whether to use E/AMID or Real MAC address (policy, not negotiation)
EMID
EMID
UNITDATA SAP
STA
MAC
STA AP
AMID used here DS
LLC layer
802.11
MAC/
encryption
Stefano M. Faccin, Nokia

21. AMID/EMID Concerns to be addressed
January 2006
Requirement P3
AMID/EMID Concerns to be addressed
Concerns raised based on previous presentations
“Real MAC must be visible for diagnostics in network”
“Real MAC must be visible for diagnostics through third part products in network”
Comments:
This are requirement for disclosing the MAC address to authorized parties in order to enable the network to function correctly, i.e. the network and/or a third party authorized by the network => different from the issue of protecting MAC address from unauthorized parties
Answers:
since the AMID is assigned in collaboration with the network, network can perform the mapping between the real MAC and the AMID
the mapping in (1) can be provided to third party solutions
Stefano M. Faccin, Nokia

22. P2: Prevent Hijack of MAC Addresses
January 2006
P2: Prevent Hijack of MAC Addresses
Initial TGu assumption was to list this and pass it to TGw. TGw decide to not address this since out of scope for TGw
Need to distinguish between
hijacking of MAC address
Pre-emption of MAC address (i.e. somebody else than STA X authenticating to the same AP with the MAC address of STA X)
Is it possible to prevent hijacking of MAC address in ?
The answer is no, unless …
… the MAC address is tied to the authentication credentials in the AAA server
This wasn't specified in i because it is out of scope of IEEE802.11
The linking can already be done today if the AAA server and AP agree on it, and it requires no changes to the at all
This solution does not belong to TGu.
However, preemption is possible  use AMID extended to the DS
AMID/EMID concept is being introduced and described for requirement P3
Stefano M. Faccin, Nokia

23. Proposal for P2 Build upon proposal for P3
January 2006
Proposal for P2
Build upon proposal for P3
With adoption of AMID for the whole DS, the station is protected once the legitimate node is connected
Stefano M. Faccin, Nokia

24. Input for P5 Potential issues with requirement: January 2006
Depending on the solution adopted for N1, this may become practically the issue of protecting beacons without requiring pre-established security associations
E.g. protect SSID broadcast in beacons, prevent rogue APs from transmitting forged beacons
So far no practical way to avoid replay attacks without a full authentication and key handshake have been identified
Discussion in TGw has also not lead to any solution
Solutions based only on broadcast of information cannot be secured
Should they be? Probably not, this is not worst than today’s situation
Solutions based on query/response before STA is authenticated and associated cannot be secured with a security association unless PKI-like solutions are adopted
Stefano M. Faccin, Nokia

25. Can P5 be addressed completely?
January 2006
Can P5 be addressed completely?
Perhaps it is not needed
Mitigation of security issues may be sufficient
For solutions based on query/response, avoid having the AP reply with a yes/no answer to make STA traps more difficult to implement => require AP to assert e.g. a list of SSID or other IEs
This is discussed more in detailed in our proposal for the Network Selection cluster of requirements
Stefano M. Faccin, Nokia

26. January 2006
Input for P6
Define how shared infrastructure architectures where the APs and network that connects them are shared by different operators will be supported.
This is an environment where the normal trust model within the DS does not apply. While the actual implementation may prove to be outside the scope of this TG, our architecture should have some idea of how this would be achieved.
“Normal trust model of the DS“
no such trust model is defined for the DS in
there is a tacit assumption that the DSM is confidential but this is not stated anywhere
Question: why does the use of shared DSM changes anything in the standard? How is this in scope of given that the DSM is explicitly undefined?
Should we consider a motion to classify this requirement “out of scope/not required”?
Stefano M. Faccin, Nokia