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