Re: [Captive-portals] [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications
"David R. Oran" <daveoran@orandom.net> Tue, 22 September 2020 21:27 UTC
Return-Path: <daveoran@orandom.net>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25423A1A03; Tue, 22 Sep 2020 14:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VNA-E81ndiS; Tue, 22 Sep 2020 14:27:43 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFAD3A1A02; Tue, 22 Sep 2020 14:27:42 -0700 (PDT)
Received: from [192.168.15.243] ([IPv6:2601:184:407f:80ce:18d1:a32d:eba0:14da]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 08MLRXiR025126 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Sep 2020 14:27:35 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "Lee, Yiu" <Yiu_Lee@comcast.com>, Michael Richardson <mcr+ietf@sandelman.ca>, captive-portals@ietf.org, homenet@ietf.org, int-area@ietf.org
Date: Tue, 22 Sep 2020 17:27:27 -0400
X-Mailer: MailMate (1.13.2r5719)
Message-ID: <D7720A77-03DF-4F4E-8E08-463DE26C914C@orandom.net>
In-Reply-To: <ca575a6b-987e-d998-2713-91e45190f5ea@cs.tcd.ie>
References: <20200922201317.097C3389D4@tuna.sandelman.ca> <15660.1600807202@localhost> <902400f2-9172-9581-25ab-59ad08e67bee@cs.tcd.ie> <D81695FF-973F-472D-BC0A-9B0F57278B21@comcast.com> <ca575a6b-987e-d998-2713-91e45190f5ea@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/RmkYWhmaNDnDtt89SocAWwaCu7g>
Subject: Re: [Captive-portals] [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 21:27:45 -0000
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-bounces@ietf.org on behalf of stephen.farrell@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-area@ietf.org, captive-portal@ietf.org, homenet@ietf.org >>> From: Michael Richardson <mcr+ietf@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+IETF@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
- Re: [Captive-portals] [Int-area] Evaluate impact … Michael Richardson
- Re: [Captive-portals] [homenet] [Int-area] Evalua… Stephen Farrell
- Re: [Captive-portals] [Int-area] Evaluate impact … Peter Yee
- Re: [Captive-portals] [Int-area] [homenet] Evalua… Lee, Yiu
- Re: [Captive-portals] [homenet] [Int-area] Evalua… Stephen Farrell
- Re: [Captive-portals] [homenet] [Int-area] Evalua… David R. Oran
- Re: [Captive-portals] [EXTERNAL] Re: [homenet] [I… Lee, Yiu
- Re: [Captive-portals] [homenet] [Int-area] Evalua… Bob Hinden
- Re: [Captive-portals] [homenet] [Int-area] Evalua… Michael Richardson
- Re: [Captive-portals] [homenet] [Int-area] Evalua… Brian Dickson
- Re: [Captive-portals] [homenet] [Int-area] Evalua… Stephen Farrell
- Re: [Captive-portals] [EXTERNAL] Re: [homenet] [I… Martin Thomson
- Re: [Captive-portals] [homenet] [Int-area] Evalua… Michael Richardson
- Re: [Captive-portals] [homenet] [EXTERNAL] Re: [I… Michael Richardson
- Re: [Captive-portals] [Int-area] [homenet] Evalua… Pascal Thubert (pthubert)
- Re: [Captive-portals] [Int-area] [homenet] Evalua… Michael Richardson
- Re: [Captive-portals] [Int-area] Evaluate impact … Derek Fawcus
- Re: [Captive-portals] [Int-area] [EXTERNAL] Re: [… Christian Huitema
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Michael Richardson
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Brian Dickson
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Michael Richardson
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Stephen Farrell
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Christian Huitema
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Peter Yee
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Michael Richardson
- Re: [Captive-portals] [Int-area] [homenet] [EXTER… Juan Carlos Zuniga
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Stephen Farrell
- Re: [Captive-portals] [Int-area] [homenet] [EXTER… Weil, Jason
- Re: [Captive-portals] [Int-area] [homenet] [EXTER… Rolf Winter
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Michael Richardson
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Stephen Farrell
- Re: [Captive-portals] [homenet] [Int-area] [EXTER… Carsten Bormann
- Re: [Captive-portals] [Int-area] [homenet] Re: Ev… Livingood, Jason