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

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2020 16:40:02 -0400

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: [email-masked], [email-masked], [email-masked]
From: Michael Richardson <[email-masked]>
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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Sep 2020 21:51:30 +0100

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:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: "Peter Yee" <[email-masked]>
Date: Tue, 22 Sep 2020 14:06:48 -0700

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:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, September 22, 2020 1:40 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Captive-portals] [Int-area] Evaluate impact of MAC address randomization to IP applications

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:
> 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 
> 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
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 22 Sep 2020 21:08:55 +0000

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.

Thanks,
Yiu

On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    Cheers,
    S.

    On 22/09/2020 21:40, Michael Richardson wrote:
    > Archived-At: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eprXSEjo$ >
    >> 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
    >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_erhCF3-A$ .
    >>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_epVo5mQQ$
    >

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Sep 2020 22:18:21 +0100

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.

Cheers,
S.

> 
> Thanks, Yiu
> 
> 
> On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell"
> <[email-masked] on behalf of [email-masked]>
> 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.
> 
>> 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$
>> From: Michael Richardson <[email-masked]> Date: Tue, 22 Sep
>> 2020 16:34:33 -0400
>> 
>> 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.
>> 
>> 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.
>> 
>> 
>>> 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 
>> -- Michael Richardson <[email-masked]>   . o O ( IPv6 IøT
>> consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> _______________________________________________ homenet mailing
>> list [email-masked] 
> _______________________________________________ homenet mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 22 Sep 2020 17:27:27 -0400

> 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.

>> [email-masked] https://www.ietf.org/mailman/listinfo/homenet

DaveO

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 22 Sep 2020 21:24:13 +0000

Noted and clear. Will keep this in mind in the next update.

Thanks,
Yiu

On 9/22/20, 5:18 PM, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

    Cheers,
    S.

    > [email-masked] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!QmyqyKwbOOxTGfm0x58b5xfYvrm-ivhzQUDCjlF7XvYCa411l20nyTY4Gc-Mvoc$
    >

---

From: Bob Hinden <[email-masked]>
Date: Tue, 22 Sep 2020 16:14:57 -0700

I have read the emails and the draft <draft-lee-randomized-macaddr-ps-01>.   I am not clear what the goal of the BOF is.

Could the proponents state it clearly?

From the agenda, Use Cases:

	• LAN gateway NAPT forwarding - (PRESENTER TBD)
	• Static NAPT policies - (PRESENTER TBD)
	• Persistent DHCP IP address assignments - (PRESENTER TBD)
	• Device-to-user or group association for malware protection - (PRESENTER TBD)
	• Device-to-user or group association for parental controls - (PRESENTER TBD)
	• Device-to-user or group association to restrict or authorize unwanted or unverified device connections to the LAN - (PRESENTER TBD)

It seems like this is a list of topics where randomized MAC addresses might break things, so I wonder what the intent is here.   No mention of the privacy benefits, or what the tradeoff are.

I note that while MAC addresses are commonly used for things like this, it’s never been very secure as it is easy on most devices to change the MAC address.   Like when some cable modems locked on to a specific MAC address, and the way to get around this was to change to a different MAC address in the device.

I also wonder how much of this is an IETF issue, vs. IEEE.

Bob

> On Sep 22, 2020, at 1:51 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> <0x5AB2FAF17B172BEA.asc>_______________________________________________
> homenet mailing list
> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2020 19:25:18 -0400

> Could the proponents state it clearly?

I can't speak for the proponents, but at the simplest, one could add:
  "how can we do X if the MAC cannot be used as identity"

    > • Device-to-user or group association to restrict or authorize unwanted
    > or unverified device connections to the LAN - (PRESENTER TBD)

I don't get the NAPT issue though.
The NAPT issues are because DHCP gave the device a different IP(v4), right?
If you solve persistent DHCP, then you solve those, don't you?

---

From: Brian Dickson <[email-masked]>
Date: Tue, 22 Sep 2020 17:13:41 -0700

On Tue, Sep 22, 2020 at 4:25 PM Michael Richardson <[email-masked]>
wrote:

>     > I have read the emails and the draft
> <draft-lee-randomized-macaddr-ps-01>.   I am not clear what the goal of the
> BOF is.
>

I think there are some environments where that isn't technically accurate,
or might not be 100% accurate.
E.g. The difference between DHCP6 and that other wacky thing that is doing
random self-assigned IPv6 addresses.

Basically if MAC addresses change during the lifetime of any assignment
(externally provided or self-assigned), the L3/L2 mapping itself also needs
to be updated or redone.

And how that is done can break security and/or connectivity and/or privacy,
or possibly all three.

(E.g. maintaining the IP address when the MAC changes, defeats at least one
possible purpose of changing the MAC.)

I sense a potential rat-hole, but also the possibility of finding common
ground to fix a bunch of things that are problematic to some degree or
another.

I'm hopeful that something like 802.1x can be made use of effectively, but
again a lot depends on the use cases and will likely require pretty deep
dives on each of the relevant technologies and implementations.

IMNSHO, MACs should be relegated to the role reflected in their name: Media
Access Control, basically a disambiguator, not an identity.

Maybe MACs should be used the way the initial values selected by the two
parties doing DH key exchange are used, just as a stepping stone in
establishing a cryptographically-strong "thing" that only they know.
I.e. use the initial MAC (regardless of what it is) as an initial layer-2
communications things, during the set-up of {whatever the BOF/WG output
is}, after which the MAC gets changed to {something else}.

The work being done by the exposure notification may be a good reference
model.
(Google Apple Exposure Notification, aka GAEN, for the SARS-CoV-2 aka
Covid-19 protocols for privacy-first automatic exposure notification over
BLE).
That too uses identifiers that are non-linkable and rotate periodically (on
the order of 10 minutes IIRC).

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Sep 2020 01:37:34 +0100

Hiya,

> Access Control, basically a disambiguator, not an identity.

With s/disambiguator/local disambiguator/ I would entirely
agree I think.

> the order of 10 minutes IIRC).

I don't think the GAEN system is a good example.

Mainly because, despite what I think are the good
intentions of all involved (that I've talked to anyway),
I doubt it could ever work reliably (and so is to some
extent theatre) but also because it's inherently vulnerable
to replay attacks, implementations can be very privacy
unfriendly, and the governance part is pretty sucky. It
also turns out that integrating GAEN into a real contact
tracing system seems quite failure prone too. (Apologies
for the self-references but our reports at [1] cover all
the above and more.)

That said, some of the protocol constructs used by GAEN may
well be good things to re-use though - there are some good
ideas there, in addition to the unjustified optimism. (*)

Cheers,
S.

[1] https://down.dsg.cs.tcd.ie/tact/

(*) "unjustified optimism" isn't quite right - I figure
it was more a case of "something must be done; <this> is
something that is less bad than <that>, therefore <this>
will be done."

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Sep 2020 10:52:20 +1000

There's an additional consideration that might be worth pulling out here.  And it's not an impact on network operations, it's a potential for applications that interact with these network services to undo the work of lower parts of their stack.

For instance, if your device connects to the same network and the same captive portal it might open a web browser to connect to that portal.  If the web browser presents the cookies it received from the portal last time they talked, it undoes the work of the OS.

Now, some implementations use these nasty browser-like things with aggressive sandboxing that don't save cookies.  That comes with other costs, but it addresses the problem up until the point that the network connection is restored and then who knows what happens once the pseudo-browser is no longer involved.

Maybe that is out of scope for your draft, but it shouldn't be out of scope for a group that attempts to look more closely at providing advice for dealing with these features.

(Does this thread really need to be cross-posted so widely?  Can we decide on a single venue?)

On Wed, Sep 23, 2020, at 07:24, Lee, Yiu wrote:
> list
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/homenet__;!!CQl3mcHX2A!QmyqyKwbOOxTGfm0x58b5xfYvrm-ivhzQUDCjlF7XvYCa411l20nyTY4Gc-Mvoc$
>     >
> 
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2020 21:17:53 -0400

> random self-assigned IPv6 addresses.

Sure.  If there is a port mapping (or PCP created incoming ACL for IPv6),
which is bound to a particular IPv6 (however assigned), and that the IPv6
changes, then the mapping will break right?
This is independant of MAC address randomization right?
If we changed the MAC address, and then kept the IP address involved, then ND
would fix things up, and things would continue just fine.

    > possible purpose of changing the MAC.)

I strongly disagree here.
We use privacy IPv6 addresses in order to keep legitimate distant end points
(and their associated snoops) from tracking one for place to place.

We use different MAC addresses for different networks to keep from being
tracked by a federation of local snoops from place to place.

We change our MAC address at the same network to hide our time of use and
presence from local snoops.  But, also to deal with malicious attackers who
put up a common ESSID ("Starbucks").   We can, and do encrypt our IPv6
address on those networks.  But, we can't encrypt our MAC address, because as
you say, it used for media access control.

    > ground to fix a bunch of things that are problematic to some degree or

I hope so too.

    > is}, after which the MAC gets changed to {something else}.

An interesting idea.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Sep 2020 21:25:59 -0400

Martin Thomson <[email-masked]> wrote:
    > Maybe that is out of scope for your draft, but it shouldn't be out of
    > scope for a group that attempts to look more closely at providing
    > advice for dealing with these features.

    > (Does this thread really need to be cross-posted so widely?  Can we decide on a single venue?)

Blame me :-)
It's only three lists.
It's not like I CC'ed to ADD, emailcore and the dns* groups :-)

I didn't think that Yiu's post to int-area would catch all the right flies.
Apparently it might get a BOF ML soon.

and I felt that it deserved wider review and excitement.
Our mailman strips off Reply-To: since we did that DMARC avoidant hack
(AFAIK), so redirecting replies only works if we all agree.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Sep 2020 07:56:43 +0000

Hello Dave and all:

So far I have not seen how the MAC randomization deals with:

- DAD - the chances of duplication seem much higher than for IPv6; maybe we can help by doing DAD with something like RFC 8505 on the first hop switch / AP.

- differentiated environments - the preferred behavior on a highway or at a coffee shop may differ from that at in a corporate or a DC network. In the corporate network, we can expect something like .1x to undo the privacy, for good reasons. And we can expect state to be maintained for each IP and each MAC. When a MAC changes, there can be unwanted state created and remaining in the DHCP server, LISP MSMR, SAVI switch,  etc... Privacy MAC is only an additional hassle that we want to minimize.

The current implementations seem to use the SSID to do something similar to RFC 7721. When you come back to the same SSID, you get the same MAC. This helps the corporate network, and is detrimental to the privacy at the coffee shop and the highway, if the same SSID is used across the country in all coffee halts and highway stops.

There appears to be work to do so that:
- the node forms a privacy MAC
- with that privacy MAC the node can do local things like 1x and DAD, if they are available
- if the visited network is recognized, the node applies a behavior (policy) that depends on the visited network
- else use a default higher privacy mode that may renew the MAC more aggressively
- only then, form IP addresses and stuff. If the MAC address was built using privacy, then we could restore the old behavior of embedding it in the IPv6 IID.

Bottom line is that the separate efforts at IETF and IEEE seem to have produced a complex overall solution, with duplicated and somewhat misaligned efforts and yet, gaps. The privacy properties of L2 and L3 addresses are not aligned to a same policy, and is not adapted to the joined network. The impact on upper layers of changing the MAC address is not fully understood. Duplicate addresses are not properly avoided at either layer and yet we pay a high broadcast price on wireless for the inefficient operation of IPv6 DAD. Hopefully we will not replicate that at L2.

This BoF may be an opportunity for IEEE and IETF to work together and converge to a better overall service to the upper layers.

Keep safe

Pascal

> From: Int-area <[email-masked]> On Behalf Of David R. Oran
> Sent: mardi 22 septembre 2020 23:27
> To: Stephen Farrell <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Int-area] [homenet] Evaluate impact of MAC address
> randomization to IP applications
> 
> > 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
> >>
> >>
> >>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/i
> >>> nt-
> area/14Skgm84GslPZ9UcGoWY3uzmK6I__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR
> 2
> >>> EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eprXSEjo$
> >>> 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
> >>> answer is that IoT devices have little reason to randomize their MAC
> >>> if they are not generally ported.
> >>>
> >>>
> >>>> https://urldefense.com/v3/__https://github.com/jlivingood/IETF109Bo
> >>>> F/blob/master/109-
> Agenda.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6u
> >>>> WBNU-xJadaznxWvwmDk2-ARoR0DYYq_e7alyc8U$
> >>>> and the proposal is in
> >>>> https://urldefense.com/v3/__https://github.com/jlivingood/IETF109Bo
> >>>> F/blob/master/BoF-Proposal-
> 20200918.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcr
> >>>> yUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eNfKGqkE$
> >>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-r
> >>>> andomized-macaddr-ps-
> 01__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU
> >>>> -xJadaznxWvwmDk2-ARoR0DYYq_erhCF3-A$
> >>>> .
> >>>>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ho
> >>> menet__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-
> xJadaznxWvwmDk2-AR
> >>> oR0DYYq_epVo5mQQ$
> >>
> >>>
> >>
> >>
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Sep 2020 08:52:51 -0400

> - differentiated environments - the preferred behavior on a highway or
    > at a coffee shop may differ from that at in a corporate or a DC
    > network. In the corporate network, we can expect something like .1x to
    > undo the privacy, for good reasons. And we can expect state to be
    > maintained for each IP and each MAC. When a MAC changes, there can be
    > unwanted state created and remaining in the DHCP server, LISP MSMR,
    > SAVI switch,  etc... Privacy MAC is only an additional hassle that we
    > want to minimize.

If we can assume 802.1X using an Enterprise scheme, and using a TLS1.3
substrate, then if the identity resides in a (Client) TLS Certificate, it
will not been by a passive attacker.

The MAC address is outside of the WEP encryption, so it is always seen, even
if the traffic is otherwise encrypted.

An EAP-*TLS based upon TLS1.2 would reveal the identity, at least the first
time.  Perhaps this is a reason to support resumption tokens in EAP-TLS!

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 25 Sep 2020 16:09:43 +0100

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 29 Sep 2020 09:22:41 -0700

> (Does this thread really need to be cross-posted so widely?  Can we decide on a single venue?)

Martin is making an important point here. There are a number of privacy
enhancing technologies deployed at different layers: MAC address
randomization at L2, Privacy addresses at L3, various forms of
encryption and compartments at L4 and above. Each of these technologies
is useful by itself, but they can easily be defeated by deployment
mistakes. For example:

1) Using the same IP address with different MAC addresses negates a lot
of the benefits of randomized MAC addresses,

2) Using a private IP address provides some privacy to client
connections. However, if the same address is also used for a publicly
accessible server, a lot of the privacy benefits disappear.

3) Using a private IP address without also using a randomized MAC
address is not going to provide privacy against local observers.

4) Web cookies and other forms of web tracking are widely used to enable
surveillance. Randomizing the MAC address and the IP address without
also doing something about web tracking is not going to provide much gains.

Defining that "something about web tracking" is challenging, given
requirements for users to identify themselves to social media sites and
other services. My personal choice would be some form of compartments,
each with their own IP address and MAC address, but opinions will
probably vary. That would be a great topic for a BOF.

-- Christian Huitema

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Sep 2020 13:29:56 -0400

> is useful by itself, but they can easily be defeated by deployment

You are spot on.
But, even your four points muddle things.

We need some diagrams that we can all agree upon, and we need to name the
different observers.

Each thing defends against different kinds of observers, and not all
observers can see all things.
Some observers may collaborate (I invoke, the WWII French resistance emotion
for this term...)
Some observers may have strong reasons not to.

    > of the benefits of randomized MAC addresses,

This assumes that a single observer can observe both at the same time.
WEP++ leaves MAC addresses visible, but encrypts the rest of L3 content.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 29 Sep 2020 10:59:37 -0700

> WEP++ leaves MAC addresses visible, but encrypts the rest of L3 content.

Any host/interface that uses ARP (not sure whether any flavor of WiFi does,
or if so which flavors), exposes the L3/L2 mapping.
So, wired IPv4 for certain (except in very locked-down enterprise settings
with static MAC addresses, perhaps) leaks this information to every host on
the same broadcast domain (same subnet and possibly additional subnets on
the same LAN/VLAN).

ARP L2 broadcasts solicit information about IP addresses, and at a minimum
each such query exposes its own MAC and IP address. Responses may be
unicast or broadcast, not sure which.
An active compromised host can easily solicit that information by iterating
over all the IP addresses on the subnet and performing an ARP for each one.

Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Sep 2020 14:41:24 -0400

<#secure method=pgpmime mode=sign>

Brian Dickson <[email-masked]> wrote:
    > Any host/interface that uses ARP (not sure whether any flavor of WiFi
    > does, or if so which flavors), exposes the L3/L2 mapping.

Yes, WIFI does use ARP. On all flavours.

Encrypted WIFI, which is mostly the default now, encrypts everything above
the L2, so the L3 part of the mapping is not seen by passive EM observers.

ARP broadcasts as you mention, so other stations on the network could see the
mapping, and the AP by default helpfully re-encrypts broadcasts to every
station.  But, that's not a passive observer: the observer is on the network.
Many APs filter ARP broadcasts as being useless chatter.

    > So, wired
    > IPv4 for certain (except in very locked-down enterprise settings with
    > static MAC addresses, perhaps) leaks this information to every host on
    > the same broadcast domain (same subnet and possibly additional subnets
    > on the same LAN/VLAN).

Yes, but that's not wifi.  Phones do not have wired connections.

    > ARP L2 broadcasts solicit information about IP addresses, and at a
    > minimum each such query exposes its own MAC and IP address. Responses
    > may be unicast or broadcast, not sure which.  An active compromised
    > host can easily solicit that information by iterating over all the IP
    > addresses on the subnet and performing an ARP for each one.

It will be good if we can get a document from the MAC randomization
proponents (if there is such a group), to explain the thread profile.
I don't think it includes active compromised hosts.

Such hosts can also ARP/ND spoof, and can even do that for the router (".1"),
capturing all the traffic on the network.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Sep 2020 20:02:59 +0100

Hiya,

> I don't think it includes active compromised hosts.

That is a problem yes. I no longer think "compromised host"
is the correct term there though. In the case of android,
we found google play services regularly calls home linking
all these identifiers and more (phone#, sim serial,
imei...) [1] for Google's own uses. I'd be very surprised
if other entities (e.g. other OS and handset makers)
weren't doing the same kind of thing (in fact I've seen
some of that but we've not yet written it up). And
supposedly innocuous "apps" can and do embed SDKs that also
do that kind of thing. [2]

I don't think "compromised" is an apt term for such a host.
Perhaps it is apt for almost the entire mobile ecosystem?

More on-topic, I do think MAC address randomisation has a
role to play for WiFi as it does for BLE, but yes there is
a lack of guidance as to how to implement and deploy such
techniques well. It's a bit tricky though as it's fairly
OS dependent so maybe not really in scope for the IETF?
(For the last 3 years I've set a possible student project
in this space, but each time a student has considered it,
it turned out "too hard";-)

Cheers,
S.

[1] https://www.scss.tcd.ie/Doug.Leith/pubs/contact_tracing_app_traffic.pdf
[2] https://arxiv.org/abs/2009.06077

---

From: Christian Huitema <[email-masked]>
Date: Tue, 29 Sep 2020 12:03:09 -0700

On 9/29/2020 10:59 AM, Brian Dickson wrote:
>
> On Tue, Sep 29, 2020 at 10:30 AM Michael Richardson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Christian Huitema <[email-masked]
>     <mailto:[email-masked]>> wrote:
>         > Martin is making an important point here. There are a number
>     of privacy
>         > enhancing technologies deployed at different layers: MAC address
>         > randomization at L2, Privacy addresses at L3, various forms of
>         > encryption and compartments at L4 and above. Each of these
>     technologies
>         > is useful by itself, but they can easily be defeated by
>     deployment
>         > mistakes. For example:
>
>     You are spot on.

There were meant as examples, so people quickly recognize that we do
have a problem. It is very true that different classes of attackers have
different views of the system, and that some defenses deter some
attackers while being bypassed by others. But I was writing a short
email, not a textbook...

>         > 1) Using the same IP address with different MAC addresses
>     negates a lot
>         > of the benefits of randomized MAC addresses,
>
> So, wired IPv4 for certain (except in very locked-down enterprise
> settings with static MAC addresses, perhaps) leaks this information to
> every host on the same broadcast domain (same subnet and possibly
> additional subnets on the same LAN/VLAN).

Yes. Michael has a point, though. Consider enterprise Wi-Fi network,
typically access controlled using 802.1x. Then, consider an attacker who
want to track which department of the enterprise is active on what
project. The attacker have not penetrated the network, maybe because
they don't want risk getting caught doing blatantly illegal stuff. They
are merely listening to the radio waves. They can see the MAC addresses,
which are outside the Wi-Fi encryption envelope, but they cannot see the
IP headers, which are encrypted. In the absence of MAC address
randomization, these MAC addresses still provide them with interesting
information, such as the graph of who connects to whom, or maybe what
type of hardware is being used. If a device is used inside and outside
the enterprise, the attackers could monitor outside activity and
identify the device owner, and then add that to the communication graph.
MAC address randomization will be a big deterrent for this class of
attackers.

> may be unicast or broadcast, not sure which.
> An active compromised host can easily solicit that information by
> iterating over all the IP addresses on the subnet and performing an
> ARP for each one.

Yes, that's another class of attackers, those that have access to the
link. For those, defense requires coordinated use of MAC address
randomization and IP address selection.

And yes to both of you, the threat model does require modeling the
capacities of attackers. That's work.

-- Christian Huitema

---

From: "Peter Yee" <[email-masked]>
Date: Tue, 29 Sep 2020 12:39:49 -0700

On 29/09/2020 12:03, Stephen Farrell wrote:

> More on-topic, I do think MAC address randomisation has a role to play for WiFi as it does for BLE, but yes there is a lack of guidance as to how to implement and deploy such techniques well. It's a bit tricky though as it's fairly OS dependent so maybe not really in scope for the IETF?
> (For the last 3 years I've set a possible student project in this space, but each time a student has considered it, it turned out "too hard";-)

As I mentioned previously, IEEE 802.11 is looking into this area, both from an operational perspective and from a privacy perspective. New IEEE 802.11 amendments (IEEE 802.11bh and IEEE 802.11bi, if approved) are being discussed. The (very) high-level documents describing each can be found at [1] and [2]. I would be happy to convey input to IEEE 802.11 regarding either document, particularly in regards to layers 3 and above. Without wishing to open up a can of worms about meeting fees, I will note that IEEE 802.11 is currently not charging for its online meetings, so if anyone wishes to take part in the random MAC address discussions directly, the next meeting will be held in early November. The RCM Study Group met yesterday morning (Americas) and will meet again in two weeks. See [3].

		-Peter

[1] https://mentor.ieee.org/802.11/dcn/20/11-20-0742-04-0rcm-proposed-par-draft.docx
[2] https://mentor.ieee.org/802.11/dcn/20/11-20-0854-06-0rcm-par-proposal-for-privacy.pdf
[3] https://mentor.ieee.org/802.11/dcn/20/11-20-0995-10-0rcm-rcm-sg-agenda.pptx

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Sep 2020 15:56:17 -0400

> That is a problem yes. I no longer think "compromised host" is the
    > correct term there though. In the case of android, we found google play
    > services regularly calls home linking all these identifiers and more
    > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very

I feel that you have confounded two things, and I don't think it's helpful.
I won't dispute your observatrions about surveillance capitalism, but I feel
that you've sensationalized what I thought was a pretty specific technical
point. Namely:
    You can't see into the L3 layer of WIFI, even when there are
    ARP broadcasts, unless your are also part of that L2 network.

I'm sure that Google Play calls home and tells Google all the your
L2/L3/IMEI/etc.  I don't doubt it.

I don't see how this relates to a local passive eavesdropping observing the
L2 frames with the encrypted L3.  One not involved with the operation
of the wifi, nor connected to that link.

Unless you are saying that Google Play operates as active eavesdropper on all
the networks on which it is connected?  I.e. it sends the L2/L3 mappings for
all devices on that network?

    > More on-topic, I do think MAC address randomisation has a role to play
    > for WiFi as it does for BLE, but yes there is a lack of guidance as to
    > how to implement and deploy such techniques well. It's a bit tricky
    > though as it's fairly OS dependent so maybe not really in scope for the
    > IETF?

The IEEE has a spec on how to do MAC address ramdomization.
It says nothing about how to automatically update the accept-list rules
created by RFC8520, or RFC8908/RFC8910 (CAPPORT).  Or EAP-FOO.

    > (For the last 3 years I've set a possible student project in
    > this space, but each time a student has considered it, it turned out
    > "too hard";-)

:-(

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 29 Sep 2020 16:10:28 -0400

Indeed, this is a continuation of the work started at IEEE 802 back in 2014
after the STRINT Workshop pre-IETF 89 [1] [2].

So far IEEE 802 has developed the (soon to be published) 802E Privacy
Recommendations [3], the recommended use of MAC address randomization in
802c [4], and now the work in 802.11 that Peter points out.

We carried out the experiment on the IETF (x2) and IEEE 802 Wi-Fi meeting
networks and we published some results at the time [5]. Even though we
found some very minor impact on DHCP, the experiment showed that MAC
address randomization worked fine. However, as we pointed out the Privacy
issues should not stop at L3.

If there is a good take away from that work, it is that Privacy cannot be
solved at a single layer, and effective solutions should be system-wide.

Juan Carlos

[1]
https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf

[2] http://www.ieee802.org/PrivRecsg/

[3] https://1.ieee802.org/security/802e/

[4] https://ieeexplore.ieee.org/document/8016709

[5] https://ieeexplore.ieee.org/abstract/document/7390443/  pre-print:
https://www.it.uc3m.es/cjbc/papers/pdf/2015_bernardos_cscn_privacy.pdf

On Tue, Sep 29, 2020 at 3:40 PM Peter Yee <[email-masked]> wrote:

> for WiFi as it does for BLE, but yes there is a lack of guidance as to how
> to implement and deploy such techniques well. It's a bit tricky though as
> it's fairly OS dependent so maybe not really in scope for the IETF?
> > (For the last 3 years I've set a possible student project in this space,
> but each time a student has considered it, it turned out "too hard";-)
>
> As I mentioned previously, IEEE 802.11 is looking into this area, both
> from an operational perspective and from a privacy perspective. New IEEE
> 802.11 amendments (IEEE 802.11bh and IEEE 802.11bi, if approved) are being
> discussed. The (very) high-level documents describing each can be found at
> [1] and [2]. I would be happy to convey input to IEEE 802.11 regarding
> either document, particularly in regards to layers 3 and above. Without
> wishing to open up a can of worms about meeting fees, I will note that IEEE
> 802.11 is currently not charging for its online meetings, so if anyone
> wishes to take part in the random MAC address discussions directly, the
> next meeting will be held in early November. The RCM Study Group met
> yesterday morning (Americas) and will meet again in two weeks. See [3].
>
>                 -Peter
>
> [1]
> https://mentor.ieee.org/802.11/dcn/20/11-20-0742-04-0rcm-proposed-par-draft.docx
> [2]
> https://mentor.ieee.org/802.11/dcn/20/11-20-0854-06-0rcm-par-proposal-for-privacy.pdf
> [3]
> https://mentor.ieee.org/802.11/dcn/20/11-20-0995-10-0rcm-rcm-sg-agenda.pptx
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Sep 2020 21:48:43 +0100

Hiya,

>     ARP broadcasts, unless your are also part of that L2 network.

I disagree about sensationalising, obviously;-)

The point is that we tended to think of a compromised host
as one that had been subject to a successful attack often
run by an unknown party. For mobile phones, the privacy
adversary seems more often to be an entity that the phone
user has accepted one way or another, whether that be the
OS or handset vendor or whoever wrote that cute spirit-
level app.

> of the wifi, nor connected to that link.

The MAC address and other identifiers are payload with the
source IP address and thus correlated at the destination
without having to locally eavesdrop. But they can be used
to later correlate with the local eavesdropper's data,
probably after that's also been centralised (perhaps via
another app using the same SDK).

> all devices on that network?

I don't believe google do that for that attack, but they
can correlate the MAC and IP addresses, yes, for all the
devices on a n/w running their OS.

>     > More on-topic, 

But yeah the above is a bit off-topic, except that it
shows there's a *lot* more to do in the mobile context
to get benefit from address randomisation.

S.

PS: to be clear - the above's not really anti-google -
we've seen similar looking traffic from handset vendors'
pre-installed s/w too.

> I do think MAC address randomisation has a role to play

---

From: "Weil, Jason" <[email-masked]>
Date: Tue, 29 Sep 2020 21:04:39 +0000

Thank you Juan and Peter for the links to the prior work in the IEEE on this topic. I have been following RCM and was actually just reading one of the publicly available draft versions of the 802E Privacy Recommendations. This work will be very useful for reference once it is published.

My interest in considering this work within the IETF goes directly to the point stated here and in the IEEE draft work that privacy doesn’t exist at one layer of then network and in fact covers all of them. The IEEE is making good progress on changes to 802 that improve the operation of the network at the data link layer. I see the WiFi Alliance is also looking at options for in its various specifications and which use cases those specs can be applied to in the realm of MAC randomization impacts.

The goal of this BoF from my viewpoint is to gauge IETF community interest on identifying and working  on updates, new work or BCP/s that would capture the privacy concerns and needs of end users as well as the impact to network operators and local network administrators (campus networks, home networks, public WiFis nets, etc). A number of areas/WG work have already been brought up in the discussion on this list.

I think some of points that came up in the IEEE and WiFi discussions are equally worth discussing in this org including the periodicity of endpoint address (or other ‘thing’ that represents a device) change.  The impact on varying trust models that would allow an end user to choose between various levels of trust and the impact on how much the network is able to remember them is also an interesting discussion topic.

Jason Weil

From: Int-area <[email-masked]> on behalf of Juan Carlos Zuniga <[email-masked]>
Date: Tuesday, September 29, 2020 at 4:11 PM
To: Peter Yee <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: Re: [Int-area] [Captive-portals] [homenet] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.

Indeed, this is a continuation of the work started at IEEE 802 back in 2014 after the STRINT Workshop pre-IETF 89 [1] [2].

So far IEEE 802 has developed the (soon to be published) 802E Privacy Recommendations [3], the recommended use of MAC address randomization in 802c [4], and now the work in 802.11 that Peter points out.

We carried out the experiment on the IETF (x2) and IEEE 802 Wi-Fi meeting networks and we published some results at the time [5]. Even though we found some very minor impact on DHCP, the experiment showed that MAC address randomization worked fine. However, as we pointed out the Privacy issues should not stop at L3.

If there is a good take away from that work, it is that Privacy cannot be solved at a single layer, and effective solutions should be system-wide.

Juan Carlos

[1] https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf

[5] https://ieeexplore.ieee.org/abstract/document/7390443/  pre-print: https://www.it.uc3m.es/cjbc/papers/pdf/2015_bernardos_cscn_privacy.pdf

On Tue, Sep 29, 2020 at 3:40 PM Peter Yee <[email-masked]<mailto:[email-masked]>> wrote:

                -Peter

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

---

From: Rolf Winter <[email-masked]>
Date: Wed, 30 Sep 2020 09:29:25 +0200

Hi,

these pointers are very useful. Thanks. I would add one more:

https://tools.ietf.org/html/rfc8386

We know for a fact that there are protocols out there, even at the 
application layer, that would thwart efforts to randomize MAC addresses. 
Of course you'd have to be connected to the same L2 network, but the 
IETF meeting network, internet cafes, campus networks... it is not 
uncommon to be connected at L2 to devices that you probably do not 
trust, manage, know about.

I think a BoF about this general topic would be interesting, but I 
believe it should be scoped tightly, so the discussion can be focussed.

Best,

Rolf

Am 29.09.20 um 22:10 schrieb Juan Carlos Zuniga:
> Indeed, this is a continuation of the work started at IEEE 802 back in 
> 2014 after the STRINT Workshop pre-IETF 89 [1] [2].
> 
> We carried out the experiment on the IETF (x2) and IEEE 802 Wi-Fi 
> meeting networks and we published some results at the time [5]. Even 
> though we found some very minor impact on DHCP, the experiment showed 
> that MAC address randomization worked fine. However, as we pointed out 
> the Privacy issues should not stop at L3.
> 
> If there is a good take away from that work, it is that Privacy cannot 
> be solved at a single layer, and effective solutions should be system-wide.
> 
> Juan Carlos
> 
> [1] 
>      > More on-topic, I do think MAC address randomisation has a role to
>     play for WiFi as it does for BLE, but yes there is a lack of
>     guidance as to how to implement and deploy such techniques well.
>     It's a bit tricky though as it's fairly OS dependent so maybe not
>     really in scope for the IETF?
>      > (For the last 3 years I've set a possible student project in this
>     space, but each time a student has considered it, it turned out "too
>     hard";-)
> 
>     As I mentioned previously, IEEE 802.11 is looking into this area,
>     both from an operational perspective and from a privacy perspective.
>     New IEEE 802.11 amendments (IEEE 802.11bh and IEEE 802.11bi, if
>     approved) are being discussed. The (very) high-level documents
>     describing each can be found at [1] and [2]. I would be happy to
>     convey input to IEEE 802.11 regarding either document, particularly
>     in regards to layers 3 and above. Without wishing to open up a can
>     of worms about meeting fees, I will note that IEEE 802.11 is
>     currently not charging for its online meetings, so if anyone wishes
>     to take part in the random MAC address discussions directly, the
>     [email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Sep 2020 13:16:34 -0400

Stephen Farrell <[email-masked]> wrote:
    >> > On 29/09/2020 19:41, Michael Richardson wrote: >> It will be good if
    >> we can get a document from the MAC randomization >> proponents (if
    >> there is such a group), to explain the thread profile.  >> I don't
    >> think it includes active compromised hosts.
    >>
    >> > That is a problem yes. I no longer think "compromised host" is the >
    >> correct term there though. In the case of android, we found google
    >> play > services regularly calls home linking all these identifiers and
    >> more > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be
    >> very
    >>
    >> I feel that you have confounded two things, and I don't think it's
    >> helpful.  I won't dispute your observatrions about surveillance
    >> capitalism, but I feel that you've sensationalized what I thought was
    >> a pretty specific technical point. Namely: You can't see into the L3
    >> layer of WIFI, even when there are ARP broadcasts, unless your are
    >> also part of that L2 network.

    > The point is that we tended to think of a compromised host as one that
    > had been subject to a successful attack often run by an unknown
    > party. For mobile phones, the privacy adversary seems more often to be
    > an entity that the phone user has accepted one way or another, whether
    > that be the OS or handset vendor or whoever wrote that cute spirit-
    > level app.

My take home from your work is that MAC address randomization is a useless
waste of time.  It causes significant costs to the network operator(s) without
actually providing any benefit to the mobile phone owner, because the
adversary is inside the device, invited in by the owner.
In such a situation, MAC randomization feels like security theatre to me.

[I'm reminded of various systems of magic in fiction, where you are safe as long
as you don't unwittingly invite the bad guys in]

You have defined the security perimeter as being from "top" of the phone.
(Between the screen and the human)

I have defined the security perimeter as being the "bottom" of the phone
(between the phone and the Internet).

I think that we can do more here, and I think that the cost to the operator
(moving from unencrypted, MAC-address excepted networks, to encrypted 802.1X
authenticated networks with provisioned identities) with some correspondant
benefits to the operator as well as the end user.

    > PS: to be clear - the above's not really anti-google - we've seen
    > similar looking traffic from handset vendors' pre-installed s/w too.

Agreed.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Sep 2020 21:03:23 +0100

Hiya,

I don't agree with that conclusion...

> In such a situation, MAC randomization feels like security theatre to me.

I think MAC address randomisation *alone* isn't very useful
but even so still has some utility as it makes some forms
of tracking (based purely on a static MAC) harder. IIRC
exactly that form of tracking was reported as being done by
the security services in Canada linking MACs seen in
Pearson with those later seen downtown or something. (I
didn't go find the reference so that may be inaccurate.)

MAC address randomisation, when well-coupled to changes
at other layers can be more beneficial. That is how the GAEN system is
designed - the beacon payload (the RPI) is
intended to change with the BLE MAC address about every
10 minutes.

Getting similar benefits for randomised WiFi MAC addresses
with IP and more layers above is hard, but it's still worth
having the basic mechanism so that people can try address those harder
problems over time.

So, no, not "theatre" but far from complete.

I'd probably also disagree with you on the practicality of
depending on 802.1X outside enterprise environments, but
that's a different topic too.

Cheers,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2020 23:58:02 +0200

On 2020-09-30, at 19:16, Michael Richardson <[email-masked]> wrote:
> the
> adversary

There may be more than one.
Of course, if you want to attack privacy, being Google or Facebook gives you unique opportunities.
That doesn’t mean you don’t want to have a seat belt any more if you have lane-keeping assistance.

Grüße, Carsten