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: int-a...@ietf.org, captive-por...@ietf.org, homenet@ietf.org From: Michael Richardson <mcr+i...@sandelman.ca> 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-20200918.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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet