Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 22 September 2020 20:34 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38783A1A23; Tue, 22 Sep 2020 13:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 YgNJQ73D1q7K; Tue, 22 Sep 2020 13:34:46 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D99B3A19C1; Tue, 22 Sep 2020 13:34:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 05774389D2; Tue, 22 Sep 2020 16:13:15 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3lgKb6nLpdWX; Tue, 22 Sep 2020 16:13:11 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 40F47389D1; Tue, 22 Sep 2020 16:13:11 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5EBAB4F5; Tue, 22 Sep 2020 16:34:33 -0400 (EDT)
To: int-area@ietf.org, captive-portal@ietf.org, homenet@ietf.org
References: <A8BB4316-BCAE-4E3C-AC3B-441D2ECB0338@comcast.com>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <86fbabc6-ecec-fe9e-593e-e6ef87f67173@sandelman.ca>
Date: Tue, 22 Sep 2020 16:34:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <A8BB4316-BCAE-4E3C-AC3B-441D2ECB0338@comcast.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/IjEjG8lK2layZRmrZcY7LevgYrs>
Subject: Re: [Int-area] Evaluate impact of MAC address randomization to IP applications
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 20:34:54 -0000

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://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and 
> the proposal is in 
> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md. 
> You can also find the draft here 
> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
> 
> 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
>