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

[Derek Fawcus]

On Tue, Sep 22, 2020 at 02:06:48PM -0700, Peter Yee wrote:
> I believe that the address randomization (Private Address) can be turned off 
> in iOS 14,
> but it seems to be a manual operation per ESSID only.

Sort of yes and no.

I happened to notice it this morning, having got IOS 14 on a device.
There is a manual configuration knob, it defaults to on.

Despite that it did (eventually) detect that the network does not support 
randomization,
and operationally disabled it, with a warning message about the privacy feature
being disabled or incompatible with the network, but with the 'private address' 
being
the built in MAC address.  Or at least it did initially before I manually 
disabled
the randomisation after noticing the warning, now it seems to only operate as a
manual on/off knob with no fallback operational disabling.

Also I happen to have a LAN, with 3 ESSIDs operating on it.
All currently using MAC filtering (yeah I know they can be spoofed).

Apple have a document describing what they desire for WiFi:
   https://support.apple.com/en-gb/HT202068

Where amongst other things, they mention not using different SSIDs for
different frequencies on the same LAN.

I guess the issue here is that when roaming between ESSIDs they'll change MAC,
affecting DHCP allocations and/or SLAAC and thereby break ongoing IP 
connectivity,
or force ARP and/or NDP re-resolution.

I'll have a go at disabling the MAC filter at some point,
and see how that affects the roaming behaviour.
Given the prevalence of broken NATs, I suspect lots of apps will just recover,
at worst after a delay.

DF

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Peter Yee]

Michael,

I believe that the address randomization (Private Address) can be 
turned off in iOS 14, but it seems to be a manual operation per ESSID only.

That said, IEEE 802.11 has a Random and Changing MAC Addresses Study 
Group that has just requested the creation of two new projects under IEEE 
802.11 (subject to the usual approval by the management layers above it). One 
will deal with operational issues that arise from random addresses and how they 
can be alleviated, if possible. The other will look more closely at privacy in 
IEEE 802.11, since MAC address randomization was a first stab at privacy, but 
it leaves many other privacy-defeating vectors unaddressed.

The Wi-Fi Alliance has the Device Provisioning Protocol (Wi-Fi 
Certified Easy Connect 
(https://www.wi-fi.org/discover-wi-fi/wi-fi-easy-connect)), which may be of use 
in environments where traditional on-boarding methods are not available, such 
as for headless or IoT devices.

-Peter

-Original Message-
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Michael Richardson
Sent: Tuesday, September 22, 2020 1:40 PM
To: captive-portals@ietf.org; home...@ietf.org; int-a...@ietf.org
Subject: Re: [Captive-portals] [Int-area] Evaluate impact of MAC address 
randomization to IP applications


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://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I>
To: int-a...@ietf.org, captive-por...@ietf.org, home...@ietf.org
From: Michael Richardson 
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://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and 
> the proposal is in 
> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-2020
> 0918.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
>


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Michael Richardson]

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: 

To: int-a...@ietf.org, captive-por...@ietf.org, home...@ietf.org
From: Michael Richardson 
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://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
>


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide



signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals