Noted and clear. Will keep this in mind in the next update.
Thanks,
Yiu
On 9/22/20, 5:18 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote:
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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!QmyqyKwbOOxTGfm0x58b5xfYvrm-ivhzQUDCjlF7XvYCa411l20nyTY4Gc-Mvoc$
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
