Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol
> But to the main point, what are we problems are we trying to solve? I may have taken us away from
> just MAC address randomization to a specific approach to both randomize an address and support
> an ability to find and authenticate devices.
I think there are two scenarios of interest. The first one is "Peer-to-peer with randomized addresses," and the second one is "randomized addresses in a stadium."
The peer-to-peer case covers for example scenarios like "Miracast." Two devices establish direct connection over Wi-Fi, without support of infrastructure services, and use it to exchange data. The current solutions are based on some form of pairing: press a button at the same time on both devices, or copy on one device the PIN displayed by the other. Once the pairing is done, the devices remember each other, so next time they come in range the users don't have to engage in another round of button pressing or PIN typing. The problem is that they currently remember each other using their MAC address. This could lead to serious privacy issues. Imaging that the phone in your pocket is paired with the smart watch on your wrist. Do you want them broadcasting unique identifiers over the radio as you walk around?
The stadium case refers to the "large network" deployments in which 46 random bits are not statistically sufficient to get out of "birthday paradox" territory. In these cases, if a device tries to use a MAC address that is "already in use," the device's connection to the infrastructure should be rejected, and the device should retry with a different MAC address. We would want a solution that does not impose an undue burden in the common case when 46 bits is statistically sufficient. We also would want a solution that cannot be trivially turned into a denial of service vector. At the same time, we want to ensure that the solution does not requires the use of long term identifiers, and certainly not exchanging long term identifiers in clear text.
Does that help?
-- Christian Huitema