Re: [STDS-802-Privacy] Topics 1&3 - MAC randomization
Hi all,
Concerning MAC randomization, there is a nice academic paper [1]
discussing the issue. In particular, section 3 of this paper presents
a method to generate random MAC address, a method to detect
collisions, and the integration within authentication mechanisms.
[1] Enhancing Location Privacy in Wireless LAN Through Disposable
Interface Identifiers: A Quantitative Analysis, Marco Gruteser, Dirk
Grunwald, Mobile Networks and Applications 10, 315–325, 2005
http://morse.colorado.edu/~timxb/5520/ho/GruteserPrivacy.pdf
Regards,
Mathieu Cunche
On 09/12/2014 01:36 AM, Zuniga, Juan Carlos wrote:
> Hi,
>
> Following up on the MAC topic, I gave an update to 802.1/802.3 at their interim about the discussion we have been having in this group.
>
> Currently 802.1 is looking at "MAC address re-usage," mainly triggered by the increasing number of Virtual Machines (VMs). However, the considerations they are discussing can very well define how we end up recommending privacy solutions here.
>
> At the moment, they consider that MAC changes will require keeping the MA-L (previous OUI) part intact, identifying hence the manufacturer, and limiting the random address generation to the rest of the EUI-48/64. For that, the locally administer bit (b2) would need to be set. The issue about discovering and resolving collisions is on their agenda, but there are no proposals yet. They believe a recommendation for the randomization algorithm would need to be made.
>
> Regards,
>
> Juan Carlos
>
> From: Zuniga, Juan Carlos [mailto:JuanCarlos.Zuniga@xxxxxxxxxxxxxxxx]
> Sent: Thursday, September 11, 2014 7:15 PM
> To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-Privacy] September 3 - Teleconference details
>
> Hi all,
>
> I think the email subject here is getting a little staled. However, in the email discussion there have been a number of very good points that will be useful for an eventual report/recommendation from the Group. Let me try to summarize the points using the topics from the Call for Contributions:
>
>
> 1. Privacy Issues at Link Layer
>
> o Use of long lasting (e.g. globally unique) identifiers
>
> § User's MAC address
>
> § SSID history broadcast with active probing (NOTE: not much discussion so far, but I think it should be added)
>
> 2. Threat model for Privacy at Link Layer
>
> o Over the air privacy against passive attackers (i.e. observers)
>
> 3. Proposals regarding functionalities in IEEE 802 protocols to improve privacy
>
> o MAC address randomization
>
> § During scanning phase (Probe REQ/RSP)
>
> § During active session
>
> o Bluetooth Privacy feature (see DCN privecsg-14-0005-01)
>
> 4. Proposals regarding measuring levels of Privacy on Internet protocols
>
> o (NOTE: nothing so far)
>
> 5. Implications of MAC address changes on
>
> o Collisions
>
> o DHCP states
>
> o IPv6 addressing
>
> o ARP/ND
>
> o Key derivation
>
> o SDN tables
>
> o Bridging/routing tables
>
> o Power utilization
>
> o Applications
>
> (Have I missed any? - Please add/correct)
>
> It is probably worth having an email thread for a discussion on some of these topics separately, so that we can later on produce some useful documentation.
>
> I'll start with one and provide some feedback to the group about the discussions during the presentations I recently gave to the 802.1/802.3 WGs.
>
> Regards,
>
> Juan Carlos
>
>
>
> From: Lee, Soo Bum [mailto:soobuml@xxxxxxxxxxxxxxxx]
> Sent: Thursday, September 11, 2014 12:43 PM
> To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx<mailto:STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx>
> Subject: Re: [STDS-802-Privacy] September 3 - Teleconference details
>
> Hello,
>
> I mostly agree with Dan's comments. Just as a minor addition, I think there are some privacy issues specific to WLAN, i.e., over the air privacy against passive attackers. Improving privacy only for the wireless part seems to have great impact considering the ever increasing number of wireless devices. Furthermore, WLAN air interface privacy can be considered separately from DS and the upper-layer protocols to some extent.
>
> Best wishes,
> Soo Bum
>
> From: Dan Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]
> Sent: Thursday, September 11, 2014 8:57 AM
> To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx<mailto:STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx>
> Subject: Re: [STDS-802-Privacy] September 3 - Teleconference details
>
>
> Hello,
>
> On 9/11/14 6:11 AM, "Piers O'Hanlon" <piers.ohanlon@xxxxxxxxxxxx<mailto:piers.ohanlon@xxxxxxxxxxxx>> wrote:
>
> On 10 Sep 2014, at 19:28, Mathieu Cunche wrote:
>
> Hello,
> On 09/10/2014 08:00 PM, Dan Harkins wrote:
> Hello,
> On 9/10/14 9:34 AM, "Piers O'Hanlon" <piers.ohanlon@xxxxxxxxxxxx<mailto:piers.ohanlon@xxxxxxxxxxxx><mailto:piers.ohanlon@xxxxxxxxxxxx><mailto:piers.ohanlon@xxxxxxxxxxxx%3e>> wrote:
> On 3 Sep 2014, at 17:43, Paul Lambert wrote:
> On 9/3/14, 9:15 AM, "Antonio de la Oliva" <aoliva@xxxxxxxxxx<mailto:aoliva@xxxxxxxxxx><mailto:aoliva@xxxxxxxxxx><mailto:aoliva@xxxxxxxxxx%3e>> wrote:
> Personally I think changing the MAC address during a session will
> probably require the re-association of the terminal and
> reconfiguration of all QoE and other services the terminals has
> activated. I think it will also have some impact in other standards
> relying on distribution of keys to authenticate the user such as IEEE
> 802.11r.
> We need to clarify what are the scenarios where the MAC address need
> to change during an association to an AP,
> Yes - this is harder. Per association is 'low hanging fruit' for privacy
> enhancement.
> Yes this would seems like a useful enhancement. Examining Apple's announcement of MAC randomisation in iOS8 for Probe Responses and Requests seems to indicate that they will not only randomise the MAC address of the probe packets, but also randomise the MAC address of the mobile when in Hot Spot/AP mode (Only APs send Responses). It's unclear how this will work until we see it in action - though we've only got to wait till next week now to try it out.
> That was not how I read Apple's announcement. It sounded like probes will come from random MAC addresses
> while association will always be from the machine's assigned MAC address. This behavior is not to provide any
> privacy enhancements to Apple's customers, it is to make it harder for companies to offer location-based services
> that do not use other Apple products.
> I also don't understand how a randomized MAC could be used in a probe response. The STA probes an AP to
> find out not only its capabilities but also the MAC address to which it should associate if the capabilities are
> acceptable. If the AP sends a random MAC address announcing its capabilities, the STA will not have useful
> information to effect an association. The Association request would go out to a MAC address that doesn't
> exist (any more).
> I think the idea is not to use a different MAC address for each probe
> response but to use a different MAC every time the AP is enabled.
> Yes this was my thinking too. I guess there could be further variations on the approach but one can't go changing the AP's MAC address very often without breaking things.
>
> For the probe request, a similar approach might by used: changing the
> MAC address every X minutes, rather than using a different one for
> each request.
> I guess there's no harm in changing the MAC src address for every packet...
>
> But Dan's point about iOS8 using a fixed MAC address on association was something I had heard might be the case - which may be a compromise that Apple had to make at this stage. I think that once a device associates and starts sending much traffic (mDNS, HTTP in cleartext) it is much harder to protect the user's privacy so the benefits of changing your MAC address on association are reduced. Though that's not to say it wouldn't be beneficial in terms of privacy - the devices just need to be much more careful about what layer 3 interactions they employ - which is more the realm of IETF and others.
>
> I think there is a benefit to associating with a random MAC address. The STA just has to stick
> to it for the duration of its (re)association to the ESS. By changing back to the machine MAC
> address to associate it allows for a consistent identity to be tracked over time and over location.
> Like I said, I think Apple's randomized MAC address scheme is merely to make it harder for
> people to provide location services to iOS devices without doing it Apple's way. They will gladly
> accept any "privacy" accolades thrown their way but I think their motive was anything but.
>
> Attached is a presentation I made to IEEE 802.11 back in March. It went over like a lead
> balloon but that was not due to any technical issues, it was pure politics.
>
> You're right about information exposed above L2 is more the realm of the IETF and others
> but if we don't decouple MAC address from that information above L2 then we will still
> provide information that could link a person to a whole bunch of privacy-enhanced blobs
> of data at L3 and above. And vice versa, merely randomizing a MAC address will not be
> much of a privacy solution if L3 and above is not privacy-enhanced.
>
> regards,
>
> Dan.
>
> Piers
>
> My two cents.
> Regards,
> Mathieu Cunche, PhD
> Associate Professor
> University of Lyon | INSA-Lyon, CITI Lab. | Inria Privatics
> Email: mathieu.cunche@xxxxxxxx<mailto:mathieu.cunche@xxxxxxxx> | Web: mathieu.cunche.free.fr
> Phone: (+33) 4 72 43 73 15
> In any event, I agree on the "low-hanging fruit" point. Changing MAC addresses during an association,
> or during a BSS transition will screw up lots of stuff. We should not bite off more than we can chew and
> this low-hanging fruit would be an appropriate morsel.
> regards,
> Dan.
> Changing during an association clearly would require changes in both AP
> and STA behavior and the need for a 802 specification.
> Such an approach (dubbed 'SlyFi') was detailed in a research paper I mentioned in my Tech Plenary talk:
> "Improving Wireless Privacy with an Identifier-Free Link Layer Protocol", MobiSys, 2008:
> http://www.cs.washington.edu/research/security/mobisys08-slyfi.pdf
> the scenarios where the MAC
> of the AP may change and the scenarios where the MAC of the terminal
> changes while moving to an AP of the same network.
> Yes, multiple APs (ESS) needs to be a use case.
> I imagine that facilities like frame forwarding in an ESS may be hampered by a randomly changing MAC address, unless it can be appropriately coordinated with the DS.
> Each of the
> scenarios will have different implications most probably.
> I also think that for the end user this will mean a short
> disconnection but if its IP address does not change (this might not be
> true in case SLAAC or DHCP with assigned IPs is used), everything will
> continue working automagically.
> IP address continuity should be a requirement ...
> Yes I agree this is should be the case - the IP address is something that is already independent of the device. Although some systems (e.g. DHCP) can base their IP address assignment decision upon the link layer address. There there are also protocols around network attachment - such as DNA (RFC4436, RFC6059) which also utilise link layer addresses. I think these protocols (and probably others) need a privacy review.
> Cheers,
> Piers
> My two cents
> Cheap price for a good set of scenarios ...
> Paul
> Br
> Antonio
> On Wed, Sep 3, 2014 at 5:51 PM, Paul Lambert <paul@xxxxxxxxxxx<mailto:paul@xxxxxxxxxxx><mailto:paul@xxxxxxxxxxx><mailto:paul@xxxxxxxxxxx%3e>> wrote:
> On 9/3/14, 7:48 AM, "Antonio de la Oliva" <aoliva@xxxxxxxxxx<mailto:aoliva@xxxxxxxxxx><mailto:aoliva@xxxxxxxxxx><mailto:aoliva@xxxxxxxxxx%3e>> wrote:
> Dear all,
> this can also be done by CLI on Linux and by the GUI in Windows, so it
> is a well known feature. I agree that manual modification is not the
> best option for the purposes of this group.
> Yes - but Bob was discussing a possible IETF trial of some sort. It
> would
> be interesting to document the impact of address changes in various
> environments.
> While the call was running, I tried changing MAC address. I lost
> connection to Wi-Fi and the web sharing, but it did reconnect. I
> suspect
> that this will generally be the case for WPA2-Perssonal implementations.
> WPA2-Enterprise (EAP based) authentication will be problematic I suspect
> when MAC address changes occur during a session. APs would either need
> to
> be participants in the address change process (e.g. BT example), or the
> changes need to be per BSS/ESS.
> Paul
> Br
> Antonio
> On Wed, Sep 3, 2014 at 4:46 PM, Paul Lambert <paul@xxxxxxxxxxx<mailto:paul@xxxxxxxxxxx><mailto:paul@xxxxxxxxxxx><mailto:paul@xxxxxxxxxxx%3e>> wrote:
> On the topic of testing the impact of randomization of MAC addresses:
> Apple computers can readily change the MAC address using the command
> line.
> Scripts and tools are available to facilitate this capability. For
> example,
> the SpoofMAC script works pretty well for manual changes and can be
> set
> to
> run on every start-up.
> https://github.com/feross/SpoofMAC
> Manual setting or per boot setting is not the optimal approach. MAC
> address
> changes should be integrated into the connection software (e.g. Wi-Fi
> supplicant) to change address in coordination with association to
> particular
> BSS/ESS.
> Paul
> From: <Zuniga>, Juan Carlos <JuanCarlos.Zuniga@xxxxxxxxxxxxxxxx<mailto:JuanCarlos.Zuniga@xxxxxxxxxxxxxxxx><mailto:JuanCarlos.Zuniga@xxxxxxxxxxxxxxxx><mailto:JuanCarlos.Zuniga@xxxxxxxxxxxxxxxx%3e>>
> Date: Tuesday, September 2, 2014 at 1:37 PM
> To: "stds-802-privacy@xxxxxxxx<mailto:stds-802-privacy@xxxxxxxx><mailto:stds-802-privacy@xxxxxxxx><mailto:stds-802-privacy@xxxxxxxx%3e>" <stds-802-privacy@xxxxxxxx<mailto:stds-802-privacy@xxxxxxxx><mailto:stds-802-privacy@xxxxxxxx><mailto:stds-802-privacy@xxxxxxxx%3e>>
> Subject: September 3 - Teleconference details
> Dear all,
> Please find below the call-in details for tomorrow¹s teleconference.
> Best regards,
> Juan Carlos
> -------------------------------------------------------
> Agenda
> -------------------------------------------------------
> - Welcome
> - Chair's slides
> - IEEE Slides
> - Group's Introduction
> - Technical Topics
> (1) Privacy Issues at Link Layer
> (2) Threat Model for Privacy at Link Layer
> (3) Proposals regarding functionalities in IEEE 802 protocols to
> improve
> Privacy
> (4) Proposals regarding measuring levels of Privacy on Internet
> protocols
> (5) Other
> - Next Steps
> -------------------------------------------------------
> Meeting information
> -------------------------------------------------------
> Topic: EC Priv Recomm SG #1
> Date: Wednesday, September 3, 2014
> Time: 10:00 am, Eastern Daylight Time (New York, GMT-04:00)
> Meeting Number: 740 470 465
> Meeting Password: privrecsg
> -------------------------------------------------------
> To start or join the online meeting
> -------------------------------------------------------
> Go to
> https://premconf.webex.com/premconf/j.php?MTID=m3817347fdb37efa239a354f
> 3d
> a2e6bfd
> -------------------------------------------------------
> Teleconference information
> -------------------------------------------------------
> Provide your phone number when you join the meeting to receive a call
> back.
> Alternatively, you can call:
> Call-in number (Premiere): 1-719-867-1571 (US/Canada)
> Show global numbers:
> https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=542167&num=1&num2
> =1
> 719-867-1571
> Attendee access code: 542167
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> 1. Go to https://premconf.webex.com/premconf/mc
> 2. On the left navigation bar, click "Support".
> To add this meeting to your calendar program (for example Microsoft
> Outlook), click this link:
> https://premconf.webex.com/premconf/j.php?MTID=m272e6fe525b4b6d87d2af77
> f9
> 792354a
> To check whether you have the appropriate players installed for UCF
> (Universal Communications Format) rich media files, go to
> https://premconf.webex.com/premconf/systemdiagnosis.php.
> http://www.webex.com
> CCM:+17198671571x5421670#
> IMPORTANT NOTICE: This WebEx service includes a feature that allows
> audio
> and any documents and other materials exchanged or viewed during the
> session
> to be recorded. You should inform all meeting attendees prior to
> recording
> if you intend to record the meeting. Please note that any such
> recordings
> may be subject to discovery in the event of litigation.
> --
> Antonio de la Oliva
> Assistant Professor
> Telematics Department
> Universidad Carlos III de Madrid
> E-mail: aoliva@xxxxxxxxxx<mailto:aoliva@xxxxxxxxxx><mailto:aoliva@xxxxxxxxxx>
> Phone: +34 91 624 8803
> Fax: +34 91 624 8749
> --
> Antonio de la Oliva
> Assistant Professor
> Telematics Department
> Universidad Carlos III de Madrid
> E-mail: aoliva@xxxxxxxxxx<mailto:aoliva@xxxxxxxxxx><mailto:aoliva@xxxxxxxxxx>
> Phone: +34 91 624 8803
> Fax: +34 91 624 8749
>
>