Feature request: use random MAC addresses when scanning

Thu Jun 12 12:14:54 PDT 2014

On Thu, 2014-06-12 at 12:25 -0500, Dan Williams wrote:
> On Wed, 2014-06-11 at 01:00 +0200, Bj?rn Smedman wrote:
> > Please don't use random MAC addresses without thinking it through
> > carefully. Depending on how you do it a whole lot of good things can
> > break:
> > 
> > 1. Software-Defined Networking (SDN), arguably the most promising
> > trend in networking research today relies heavily on MAC addresses as
> > unique identifiers. A growing body of work applying SDN principles to
> > Wi-Fi (e.g. CloudMAC [1], Odin [2] and our very own Anyfi.net [3])
> > uses the MAC address in probe requests to do *good*, like providing
> > seamless and secure access to your favorite Wi-Fi networks on the go
> > [4].
> 
> (Preface: I'm curious how Apple does the randomization for Probe
> Response frames; is that for hotspot/IBSS?  Anyway...)
> 
> I'm not sure how any of this would be affected by random MAC addresses
> when *scanning* though, could you explain?  I'm also assuming that when
> communicating with the AP to which you are actually associated, or which
> you would like to associate at some point in the future (ie, including
> preauthentication), the device would use its normal MAC address.  Thus
> when the AP/network is actually servicing the client and dedicating
> resources to it, the MAC address would be correct and known.

So it's been explained to me, and I actually went and read the stuff all
the way through now.  Yes, randomized MACs when scanning will likely
break the AnyFi products.  But at least at this point, won't they all be
broken for iOS 8 users too?

I'd think that sending a Probe Request with an AnyFi specific IE with
the device's identifying information in it (suitable hashed/encrypted
and periodically changing of course) would be a much more robust
mechanism instead of relying on probe requests (which I don't think were
ever envisioned for something like this).  But that obviously requires
changes on the STA side software, which I'm sure you're trying to
avoid...

Dan

> > 2. As Jouni points out there's a number of corner cases... One is how
> > Wi-Fi chipsets typically use an "ack filter" to support multiple
> > virtual Wi-Fi interfaces, and how assigning random MACs to such
> > interfaces could cause the hardware to start acking frames destined
> > for other STAs. Not good.
> 
> Were I implementing this, I certainly wouldn't change the MAC address of
> the station at all.  It would stay the same as it always has.  Simply
> that the drivers would generate a random MAC address and use that in the
> outgoing Probe Request frames when conducting a scan.  I would *not* use
> the random MAC address when sending Probe Request frames to an AP during
> the association procedures.
> 
> > 3. I'm sure there's a bunch of other problems that nobody has thought
> > of yet... That's why we have the IEEE Standards Assocation, so that we
> > can carefully think through and define the interface between network
> > and device. They could have opted for random MACs in general back when
> > IEEE 802 went to the ballot, but they didn't... perhaps wisely, who
> > knows.
> > 
> > With that said I can certainly see the need for privacy. If something
> > has to be done now (before standardization can run its course) I think
> > we should take a conservative approach. Some thoughts that come to
> > mind:
> > 
> > A. Scanning with a random MAC should IMHO be seen as sort of the Wi-Fi
> > equivalent of an incognito browser window: sure you can browse the web
> > with cookies and javascript disabled, but you can't expect to always
> > see the same thing that you'd see in a normal browser window.
> 
> I'd like to know more about the corner cases from a network POV (not a
> driver POV).  What are the actual issues with using a random MAC address
> for scans?  Why is this any different than a stranger walking by on the
> street with a phone in his/her pocket, which happens to be scanning but
> will never actually associate with the network?
> 
> > B. Like the incognito browsing mode the "incognito scan" doesn't come
> > with an absolute guarantee of privacy. A malicious tracking device
> > could e.g. answer all probe requests from random MACs with a storm of
> > probe responses containing commonly used SSIDs... As I interpret the
> > Apple slide [5] an iOS 8 device with one of these SSIDs in its
> > preferred network list would then most likely transmit an
> > Authentication frame with the device's real (universal) MAC address.
> > For real privacy we need new standards.
> 
> This has been the case pretty much forever, with most consumer
> implementations AFAIK.  Windows, Mac OS X, iOS, Linux, etc.  So you are
> completely correct, there are ways to read the real MAC address, but if
> this attack gets widespread, I'd expect some more compensation on the
> STA side to detect it.
> 
> An approach might be to save the list of known BSSIDs for common
> networks like 'linksys' that you  have successfully authenticated to
> before, and if the newly seen AP (or malicious tracking device) does not
> use that BSSID, then ignore the request.  Further, the AP/malicious
> device would have to guess the correct security parameters, otherwise
> clients should refuse to authenticate.  It's pretty dumb to just accept
> that all "linksys" access points, regardless of their security IEs, can
> be associated with, so I'd expect most clients to be fairly well-behaved
> here already.
> 
> > C. IMHO this "incognito scan" operation should be considered a third
> > type of scan, alongside the current active and passive scan types.
> > This implies that it shouldn't be a static option in a configuration
> > file, but instead a parameter in the DBus API
> > (type=passive|incognito|active) or similar.
> 
> I think this goes back to A.  What are the actual issues here that
> interfere with network operation.  I'm not saying your concerns are
> invalid, not at all.  I'm just trying to understand the implications.
> 
> > D. Personally I think it's a reasonable to prioritize privacy over
> > connectivity when my device is in standby, i.e. I'd like my connection
> > manager to issue passive scan commands in this state. If it has to
> > talk GAS/ANQP (to connect to an 802.11u / Hotspot 2.0 network) then
> > I'd be happy for the connection manager to issue an incognito scan
> > command now and again, while my device is in standby.
> > 
> > E. When I'm actively using my device on the other hand I prefer that
> > it can connect to whatever network there is (be it hidden or
> > SDN-based) without fuss. To me that's more important than the very
> > marginal effect it might have on my privacy. So, for me at least, the
> > golden rule of scanning should be: "when the device wakes up due to
> > user input do a real active scan."
> 
> Again, I'd assume (possibly wrongly) that the random MAC would only be
> used for network discovery, and not for Probe Requests done during the
> actual network association process.  So active use, when associated with
> or associating to an SSID, would still use the real MAC address.
> 
> But, since I'm clearly not going to be the one doing the implementation
> (I'd just be a consumer of it), I should probably defer to Jouni or
> Johannes to see how they'd implement it driver-side.
> 
> Dan
> 
> > F. But everyone's entitled to their own opinion, and privacy vs.
> > functionality is certainly an area where opinions differ a lot. For
> > that reason I think this should be an option for the end-user, and a
> > conservative approach dictates that it should probably be off by
> > default.
> > 
> > To summarize I'd rather see this go through standardization within the
> > IEEE. An amendment for improved privacy is sorely needed. That's my 2
> > cents.
> > 
> > Cheers,
> > 
> > Bj?rn
> > 
> > 1. http://teampal.mc2lab.com/attachments/682/p393-vestin.pdf
> > 
> > 2. http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p115.pdf
> > 
> > 3. http://anyfi.net/documentation#a_how_it_all_fits_together
> > 
> > 4. http://static.anyfinetworks.com/anyfi-sdwn-concepts-wp-20140514.pdf
> > 
> > 5. https://twitter.com/fredericjacobs/status/475601665836744704
> > _______________________________________________
> > HostAP mailing list
> > HostAP at lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap