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

2020-09-30 Thread 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

___
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

2020-09-30 Thread 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

2020-09-30 Thread 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
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

2020-09-30 Thread 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
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] [EXTERNAL] BoF proposal: Evaluate impact of MAC address randomization to IP applications

2020-09-30 Thread Eric Vyncke (evyncke) 
Yiu,

Thank you for your reply.

My first two points are about the wiki 
https://trac.tools.ietf.org/bof/trac/wiki
 where the BoF proponents should indicate the expected number of people and the 
potential conflict with other WG meetings.

While the ‘expected number of people’ is not really relevant for an on-line 
meeting, my estimate is that there will be more than 50 participants.

Finally, in the list of other WG meetings that could create a conflict for the 
participants, I suggest to add ‘capport’ WG 
https://datatracker.ietf.org/wg/capport/charter/ (this email is posted on this 
WG meeting) as IMHO capport participants could be interested in MADINAS.

Regards

-éric

From: "Lee, Yiu" 
Date: Wednesday, 30 September 2020 at 06:17
To: Eric Vyncke , "captive-portals@ietf.org" 
, "Livingood, Jason" , 
"jason.w...@charter.com" 
Cc: Magnus Westerlund , Erik Kline 
, Roman Danyliw , Benjamin Kaduk 
, "martin.h.d...@gmail.com" 
Subject: Re: [EXTERNAL] BoF proposal: Evaluate impact of MAC address 
randomization to IP applications

Hi Eric,

Sorry for the delay.  Comments inline:

Thanks,
Yiu

From: "Eric Vyncke (evyncke)" 
Date: Tuesday, September 29, 2020 at 8:35 AM
To: "captive-portals@ietf.org" , Jason Livingood 
, "Lee, Yiu" , 
"jason.w...@charter.com" 
Cc: Magnus Westerlund , Erik Kline 
, Roman Danyliw , Benjamin Kaduk 
, "martin.h.d...@gmail.com" 
Subject: [EXTERNAL] BoF proposal: Evaluate impact of MAC address randomization 
to IP applications


Jason, Jason, Yiu,



Based on the previous email thread, may I suggest a couple of items to improve 
the BoF proposal (wiki/agenda) ?

- I guess that there will be more than 50 people based on the initial reactions

- adding capport as conflict to be avoided for the BoF

[YL] Can you elaborate?



- adding a link to draft-lee-randomized-macaddr-ps

[YL] Will do



- assuming that it is too early to form a WG, please state the status of ‘non 
WG forming’

[YL] Noted



- putting  the description & agenda on the wiki 
https://trac.tools.ietf.org/bof/trac/wiki
 before this Friday 2nd of October deadline

[YL] Will work on it tomorrow.



- starting to find a potential chair who is not a proponent

[YL] Ok



- Adding discussion about privacy impact on the agenda is important or even 
critical

[YL] OK



- adding IEEE coordination is also important (could be handled before the 
potential BoF)

[YL] JW will help here.





More specific to draft-lee-randomized-macaddr-ps-01, here are a couple of 
comments (mostly details):

-  MAC addresses are not always 48 bits long

-  MAC addresses are not always assigned by manufacturers (think VM)

-  Suggest to distinguish between ‘stable’ and ‘static’ and 
‘persistent’ MAC address

-  Of course BCP 14 is no more RFC 2119 ;-)

-  PS-04 is more a requirement than a problem statement

[Y] We will add these to 02.





Hope this helps and happy to continue the discussion of course ;-)

[YL] Thanks!





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