On 22 Sep 2020, at 17:18, Stephen Farrell 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.
Right. it would not advance the case to introduce (or start using)
something else bout the device that can be tracked and/or provide
likability and thereby damage privacy in order to preserve the
randomized MAC address machinery.
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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
DaveO
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
