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

[Stephen Farrell]

Hiya,

I don't agree with that conclusion...

On 30/09/2020 18:16, Michael Richardson wrote:
> 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 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.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Stephen Farrell]

Hiya,

On 29/09/2020 20:56, Michael Richardson wrote:
> 
> Stephen Farrell  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.

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.

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

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

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

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
> > 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";-)
> 
> :-(
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> 
> ___
> homenet mailing list
> home...@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Stephen Farrell]

Hiya,

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



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Stephen Farrell]

Hiya,

On 23/09/2020 01:13, Brian Dickson wrote:
> IMNSHO, MACs should be relegated to the role reflected in their name: Media
> Access Control, basically a disambiguator, not an identity.

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

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

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;  is
something that is less bad than , therefore 
will be done."


> 
> Brian
> 
> 
> ___
> homenet mailing list
> home...@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Stephen Farrell]

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"
> 
> 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-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://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_e7alyc8U$
>>>

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

[Stephen Farrell]

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: 
> 
> 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
> 
> 
> ___
> homenet mailing list
> home...@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals