Huh? Almost every cryptographic session protocol starts out with the parties sending unauthenticated data of some sort to each other. Having a way for a party to send a blob as part of its request to be let in is straightforward.
Plus we’re taking about WPA, which, AFAIK, still uses a horrible hack for EAP even in WPA3, and as you can see mentioned elsewhere in the comments, EAP makes a pretty strong showing in its quest to be the worst widely-used example of giving an unauthenticated party actual access to the network as part of the authentication flow.
Their was a defcon or a blackhat talk on this issue. Even though the data might be encrypted....developers can leak so much metadata via the handshake that you can build profiles and track devices
The entire point of what I’m suggesting is to have a device identify itself.
If you set your phone to randomize its MAC address, then it should not send anything that specifically identifies it. If you ask your printer to connect to your corporate wireless network and you tell it to use WPA4-self-provisioning or whatever it’s called, then it should fully identify itself. Also, it’s a printer, and anyone in WiFi range is presumably privy to its existence.
Sure, if someone else spoofs the network, then they might collect the printer’s provisioning info, but one way or another the printer needs to decide to trust whatever network it ends up connecting to. And with a sufficiently well designed protocol, if the printer connects to the wrong network, then the owner of that network can’t actually impersonate the printer to the real network, because the derived keys won’t match.
Plus we’re taking about WPA, which, AFAIK, still uses a horrible hack for EAP even in WPA3, and as you can see mentioned elsewhere in the comments, EAP makes a pretty strong showing in its quest to be the worst widely-used example of giving an unauthenticated party actual access to the network as part of the authentication flow.
Doing this right is not that complicated.