Hi Michael,
Thanks for the notes. At this stage, our #1 objective is to document the use
cases that may broke and propose best practice to transition to dynamic
mac-address. We don't have the full picture of the impact. We think IETF is a
good platform to gather more information.
Thanks,
Yiu
On 9/22/20, 4:34 PM, "Int-area on behalf of Michael Richardson"
<int-area-boun...@ietf.org on behalf of mcr+i...@sandelman.ca> wrote:
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://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWZ_LjWDQ$
and
> the proposal is in
>
https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWZbxZn_w$
.
> You can also find the draft here
>
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWBEXWl54$
.
>
> 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
>
_______________________________________________
Int-area mailing list
int-a...@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgW20rPBDw$
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
