Hi Stephen,
Thanks for the notes. Actually, we believe that there are good privacy reasons
to randomize mac-address. This BoF isn't trying to "fix" randomized
mac-address. On the contrary, we want the community to embrace it. In order to
ease the anxiety for transitioning, we want to document what may break and
propose best practice to transition to dynamic mac-address.
Thanks,
Yiu
On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell"
<int-area-boun...@ietf.org on behalf of stephen.farr...@cs.tcd.ie> wrote:
That agenda and draft seem to make the seemingly common
enough mistake of only focusing on what a new privacy or
security mechanism breaks and glossing over the good
reasons why people introduce these mechanisms. I hope the
BoF proponents fix that because otherwise they may end up
giving the impression that they would prefer to not see
the privacy benefits (which I'd guess is not their goal
at all). One reason those good reasons need to be included
is that they constrain the kinds of additions that might
make sense to better handle the new mechanism.
We've seen a number of these kinds of reactions and I
figure it'd really be better if the reaction were not to
appear purely reactionary;-)
If that were fixed, then there may be a better discussion
of what, if any, additional things need doing. If that is
not fixed, I'd not be surprised if the putative BoF were
to devolve into a "it's bad" vs. "no, it's good" bun fight
that won't really take us further.
Cheers,
S.
On 22/09/2020 21:40, Michael Richardson wrote:
>
> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eprXSEjo$
>
> 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://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_e7alyc8U$
and the
>> proposal is in
>>
https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eNfKGqkE$
. You
>> can also find the draft here
>>
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_erhCF3-A$
.
>>
>> 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
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_epVo5mQQ$
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
