Feature request: use random MAC addresses when scanning

Thu Jun 12 10:25:38 PDT 2014

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.

> 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