Hiya, On 22/09/2020 22:08, Lee, Yiu wrote: > 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.
Sure, I get that. However, we've seen a number of these efforts start thusly but end up being perceived to be partly trying to unwind the privacy benefits, so I think a good way to avoid that mis-perception is to also present the reasons for (in this case, MAC address randomisation) as fully as the description of the challenges caused. Cheers, S. > > 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 >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
