Michael,
I believe that the address randomization (Private Address) can be
turned off in iOS 14, but it seems to be a manual operation per ESSID only.
That said, IEEE 802.11 has a Random and Changing MAC Addresses Study
Group that has just requested the creation of two new projects under IEEE
802.11 (subject to the usual approval by the management layers above it). One
will deal with operational issues that arise from random addresses and how they
can be alleviated, if possible. The other will look more closely at privacy in
IEEE 802.11, since MAC address randomization was a first stab at privacy, but
it leaves many other privacy-defeating vectors unaddressed.
The Wi-Fi Alliance has the Device Provisioning Protocol (Wi-Fi
Certified Easy Connect
(https://www.wi-fi.org/discover-wi-fi/wi-fi-easy-connect)), which may be of use
in environments where traditional on-boarding methods are not available, such
as for headless or IoT devices.
-Peter
-----Original Message-----
From: Captive-portals [mailto:[email protected]] On Behalf Of
Michael Richardson
Sent: Tuesday, September 22, 2020 1:40 PM
To: [email protected]; [email protected]; [email protected]
Subject: Re: [Captive-portals] [Int-area] Evaluate impact of MAC address
randomization to IP applications
Damn. Spelt captive-portal without the s again. Reposting, sorry for
duplicates.
I hate when WG names and list names do not match, and that we can't have
aliases.
And I think that reply-to gets filtered.
Archived-At:
<https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I>
To: [email protected], [email protected], [email protected]
From: Michael Richardson <[email protected]>
Date: Tue, 22 Sep 2020 16:34:33 -0400
This thread was started today on the INTAREA WG ML.
While I don't object to a BOF, I don't know where it goes.
What I see is that much of this problem needs to be resolved through increased
use of 802.1X: making WPA-Enterprise easier to use and setup, this changing
core identity from MAC Address to IDevID.
My understanding is that Apple intends to randomize MAC every 12 hours, even on
the same "LAN" (ESSID), and that they will just repeat the WPA
authentication afterwards to get back on the network. If the per-device
unique policy (including CAPPORT authorization) can be tied to the device
better, than the MAC address based "physical" exception can be updated.
But, WPA-PSK doesn't work, because it does not, in general, distinguish between
different devices.
It can be made to work if every device is given a unique PSK, and there are
some successful experiments doing exactly that. Mostly it just works, but the
challenge is communicating the unique PSK through an unreliable human.
BRSKI can certainly do this, and it can leverage that unencrypted ESSID present
at most hospitality locations to get onto the encrypted WPA-Enterprise. Or
BRSKI-TEEP, or some other BRSKI-EAP method. The unencrypted SSID is not going
away at those locations.
Thus QR-code based methods are best, yet those do not work for many IoT
devices. EMU's EAP-NOOB can help in certain cases, but we, as a community
need be clear on what direction we want to go. One answer is that IoT devices
have little reason to randomize their MAC if they are not generally ported.
On 2020-09-22 3:49 p.m., Lee, Yiu wrote:
> Hi team,
>
> We proposed a BoF. The agenda is in
> https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and
> the proposal is in
> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-2020
> 0918.md. You can also find the draft here
> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
>
> At this stage, we are looking for inputs for more use cases and
> interests of working together in this domain. Please post your
> comments in the mailing list.
>
> Thanks
>
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
