[RFC PATCH 0/1] wpa_supplicant: Implement SSID-based MAC address randomization

[João Lucas]

Hi, thanks for the feedback.

On Feb 02 12:59, Jouni Malinen wrote:
> On Thu, Jan 23, 2025 at 03:41:29PM +0000, João Lucas wrote:
> > The purpose of this patch is to allow configuring wpa_supplicant to generate
> > pseudo-random MAC addresses by hashing (sha256) the SSID together with the
> > permanent address, just like iwd does when the AddressRandomization option is
> > set to "network". This allows having a unique consistent address for each
> > network without the need for additional per-network manual configuration.
> 
> Lots of this description from the cover letter should really be in the
> commit message within the actual PATCH 1/1 email..

Understood.

> While it might be fine to use SHA256, or maybe more appropriately
> HMAC-SHA256(permanent-address, SSID), if permanent-address were a truly
> secret value that is never exposed. However, it seems quite likely that
> the permanent address gets exposed, e.g., if there are other network
> blocks where address randomization is not enabled or even if such cases
> have existed in the past. If a third party knows the permanent address,
> it is straightforward to confirm whether a random address used in
> another network is based on this scheme and as such, track the device.
>
> In other words, it is much better to use a truly random value that is
> generated independently for each network profile. If there is desire to
> avoid having to store such random value separately, I would recommend
> finding something else to use as the supposedly secret part in the
> derivation. This could be a single randomly generated seed value or some
> other system specific information that is not exposed over the air (and
> that could be concatenated with the permanent address, if desired).

I took inspiration from iwd, which also does it this way, but I totally agree
that this might not be the best approach for having a per-network generated MAC
address, for the reasons you've described, and so my other idea is this:

When mac_addr=3, and mac_value is omitted, fully randomize it and write it to
the config (currently it defaults to all zeroes, resulting in an error). Does
that seem like a preferable approach? If so, should I just do that and forget
all about the SSID thing?

For this method I'd appreciate some suggestions on how I'd go about implementing
it, such as: is there any reference code that automatically writes things to the
config? Does it always require manually issuing the save command?

> > Also, if I may suggest: I think it would make more sense to put randomization
> > style and randomization "range" (full/same_oui) into separate options, since
> > this range would also be applicable to potential future styles such as this one.
> > 
> > What do you think? Is this something worth perfecting, or is there no intention
> > in getting such feature merged?
> 
> To be frank, I don't really want to see a large number of new slightly
> different way of generating random MAC addresses to be added. I think
> there are already unnecessarily many, but things come up when someone
> decides to make a product requirement of a specific way of doing this
> and not allowing any other option.. In any case, no, I don't think this
> part is worth perfecting since the current cases will need to continue
> to be maintained for existing users and I don't particularly want to
> promote easiness of adding yet more styles.

Ouch, this is exactly the part that I've pretty much finished doing yesterday.
I'm attaching it in case you want to take a look.

I also don't really see the point in keeping the OUI octets when randomizing the
MAC address (assuming that's the "unnecessarily many" you are referring to), but
since it is such a common feature I figured someone might have a use case for
it, and the idea of putting it into a separate option was to not have to
implement 2 options for each potential new functionality.  But if we can all
agree that it is pointless to allow keeping OUI for the proposed randomization
style, that's cool with me.

Thanks,
jlucas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Implement-mac_addr_range-option-for-same-OUI-randomi.patch
Type: text/x-diff
Size: 13816 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20250202/c28d50c3/attachment.bin>