doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 1 Session MAC Address For Anonymity Date: 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, 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. Authors: NameOrganization Jon Stefano FaccinNokia

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 2 Abstract Proposes the use of “Session MAC Address” by STAs in order to provide “on air” anonymity and prevent the tracking of station mobility patterns

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 3 The Anonymity Problem Currently stations use a fixed MAC address that is unique worldwide Stations that visit public access areas leave a record of their MAC address There are many ways to link MAC address to identity –Link MAC address to hotel registration –Link MAC address to credit card information –Link MAC address to purchase records Once MAC address is linked to identity, user can be tracked –Businesses can track which people enter their building and for how long –Coffee bars can profile your travel behaviour through registering changes of location –etc. In general the ability to track individual users is divisive and could be used for a range of purposes from unwanted surveillance to crime

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 4 Two cases of problem User connecting to service –Service provider will usually require authentication and authorisation –Therefore Service provider knows identity anyway –Therefore MAC anonymity does not protect identity tracking –Anonymity only possible through independent authentication (see next slide) User probing service –User’s STA issues probe requests, looking for service –User will probe both trusted and untrusted networks –User does not join untrusted network - but MAC address may disclose identity –Therefore MAC address anonymity is important to avoid identity tracking

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 5 First case: Secure Anonymous Service Access Idea is that user is securely authenticated but the identity is protected Requires separation of authentication and service networks User identification and authorization performed at higher layers with trusted party Authentication not based on global MAC address, but on higher layer identifier Locally assigned MAC address used for authorised session connection New MAC address assigned for each session No relationship between identity and session MAC address

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 6 Example, anonymous service access Service Provider Network AP Service Router Trusted Validator AAA STA Authentication Keys Anonymous MAC address required in this zone

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 7 Second case: Avoiding Identity compromise on the wireless link Protect against identity disclosure during probing Protect against snoopers scanning wireless network Does not protect against identity tracking when user connects to service

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 8 Anonymous Probing Trusted Service AP STA Anonymous MAC address required in this zone AP Untrusted Service

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 9 Anonymous Probing - issues To avoid identity disclosure during probing, the MAC address sent over the air needs to be unconnected to identity This also protects against 3 rd party network snoopers To achieve this we propose that a “Session MAC address” be issued by the AP The “Real MAC address” can be used inside STA protocol stack and on wired network

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 10 Session MAC address domain AP Client Real MAC Address Convert Address Session MAC Address Real MAC Address PTK Application Real MAC Sess. MAC Real MAC Network

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 11 Session MAC Address Allocation MAC Addresses are usually globally unique –but “Local administration bit is available” –“Universe” of the MAC address is just the BSS Session MAC Address is only valid for a single BSS. STA must acquire new address if transitions to new AP Intent of Local Administration is a “manual process” where addresses are allocated and logged to prevent duplication –Can we create automatic allocation in a way that guarantees no duplication? Allocation by “random number” has been rejected by RAC –Automatic allocation might be OK if it assures no duplication

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 12 Additional requirement AP must learn real MAC Address of STA –Can be sent securely as part of handshake –Not needed until DS is open (Real MAC Address not needed for management frames) All existing provisions of i are unchanged.

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 13 Allocation Approaches AP is responsible for allocation of Session MAC addresses Managed (Non-Volatile Storage) –Start with low value and allocate block of addresses (say 1024). –Write block limit to NV memory. –Allocates more blocks as required and update NVM –On reboot start with last written bound from NVM Unmanaged (no Non Volatile Storage) –Start with true random value –Follow block allocation procedure –If block exceeds address range loop to low value.

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 14 Distribution of MAC to STA The STA needs to obtain a session MAC address from the AP prior to starting the association attempt Various methods are possible: –Specific request mechanism –Advertising by AP –Piggyback on probe messages Need to ensure unique MAC address issued in case of two STA joining in parallel (race condition)

doc.: IEEE /0170r0 Submission March 2005 Jon Edney, Stefano Faccin, NokiaSlide 15 Summary Use of Session MAC address: –provides MAC address anonymity –Solve identity disclosure during probing