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

[Carsten Bormann]

On 2020-09-30, at 19:16, Michael Richardson  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

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

Re: [homenet] [Captive-portals] [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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

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

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.

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


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






signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Philip Homburg]

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

Observer may be the wrong term, the more standard term is attack scenario.

Some attacks are passively observing the network, but many attacks are
more complex than that. For example, an application may phone home, an
attacker may actively probe a network, an attacker may combine different
pieces of information.

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

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

[Rolf Winter]

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


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


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



___
Int-area mailing list
int-a...@ietf.org 
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
int-a...@ietf.org
https://www.ietf.org/mailman/listinfo/int-area





smime.p7s
Description: S/MIME Cryptographic Signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet