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

[João Lucas]

Thanks for the reply. First of all, I want to point out that I didn't receive it
in my inbox (I wasn't subscribed to the list) and only found out about it on the
mailing list web archive, so hopefully I get the headers right. Also it was my
first time writing to a mailing list so please let me know if there's anything
I'm doing wrong.

On Jan 24 12:36, Michael Richardson wrote:
> João Lucas <jlucas at disroot.org> wrote:
>     > Hello,
> 
>     > 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.
> 
> Thanks. This would result in per-network-generated MAC: PNGM.
> Please see:
>   https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/
>   section 6 ---

While the end result would be similar in most cases, the linked document does
mention that PNGM should be stored on non-volatile storage, which this patch
does not do since it derives the address each time.

But regarding that definition, I also thought about implementing a way of fully
randomizing the address and writing it to the network config, and the idea was
to use the existing option mac_addr=3 and populate mac_value if omitted. But
that discussion might be for a separate thread.

>     > 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.
> 
> Agreed.

Great! I'll start looking into that. Also, it's important to discuss what to do
about the existing options (RANDOM vs RANDOM_SAME_OUI): Break compatibility?
Implicitly set the appropriate range for legacy options? Which one takes
precedence if the range is also explicitly set in the config?

If we were to break compatibility, we could get rid of RANDOM_SAME_OUI (which
could still be achieved by using RANDOM together with the appropriate range
option) and put DERIVED_FROM_ESS (or whatever we end up naming it) in its place
(mac_addr=2), which would solve the INT_RANGE problem that I explained in the
cover letter.

>     > wpa_supplicant: Implement SSID-based MAC address randomization
> 
> I suggest using the terms that madinas made up.

I'm open to suggestions on naming things, but assuming you are referring to the
term PNGM, it may not be ideal considering what I pointed out regarding
non-volatile storage and other possible policies that would better qualify as
PNGM.

> (Note that one would ideally use an entirely random mac address when
> soliciting for networks.)

Yes, and if I understand it correctly, that can already be achieved by setting
preassoc_mac_addr to 1 or 2. Not sure if it would make sense to enforce it with
PNGM, if that's what you're suggesting.

Thanks,
jlucas