Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-Privacy] September 3 - Teleconference details


  Hello,

On 9/11/14 6:11 AM, "Piers O'Hanlon" <piers.ohanlon@xxxxxxxxxxxx> wrote:

On 10 Sep 2014, at 19:28, Mathieu Cunche wrote:

Hello,
On 09/10/2014 08:00 PM, Dan Harkins wrote:
  Hello,
On 9/10/14 9:34 AM, "Piers O'Hanlon" <piers.ohanlon@xxxxxxxxxxxx<mailto:piers.ohanlon@xxxxxxxxxxxx>> wrote:
On 3 Sep 2014, at 17:43, Paul Lambert wrote:
On 9/3/14, 9:15 AM, "Antonio de la Oliva" <aoliva@xxxxxxxxxx<mailto:aoliva@xxxxxxxxxx>> wrote:
Personally I think changing the MAC address during a session will
probably require the re-association of the terminal and
reconfiguration of all QoE and other services the terminals has
activated. I think it will also have some impact in other standards
relying on distribution of keys to authenticate the user such as IEEE
802.11r.
We need to clarify what are the scenarios where the MAC address need
to change during an association to an AP,
Yes - this is harder.  Per association is ‘low hanging fruit’ for privacy
enhancement.
Yes this would seems like a useful enhancement. Examining Apple's announcement of MAC randomisation in iOS8 for Probe Responses and Requests seems to indicate that they will not only randomise the MAC address of the probe packets, but also randomise the MAC address of the mobile when in Hot Spot/AP mode (Only APs send Responses). It's unclear how this will work until we see it in action - though we've only got to wait till next week now to try it out.
  That was not how I read Apple's announcement. It sounded like probes will come from random MAC addresses
while association will always be from the machine's assigned MAC address. This behavior is not to provide any
privacy enhancements to Apple's customers, it is to make it harder for companies to offer location-based services
that do not use other Apple products.
  I also don't understand how a randomized MAC could be used in a probe response. The STA probes an AP to
find out not only its capabilities but also the MAC address to which it should associate if the capabilities are
acceptable. If the AP sends a random MAC address announcing its capabilities, the STA will not have useful
information to effect an association. The Association request would go out to a MAC address that doesn't
exist (any more).
I think the idea is not to use a different MAC address for each probe
response but to use a different MAC every time the AP is enabled.
Yes this was my thinking too. I guess there could be further variations on the approach but one can't go changing the AP's MAC address very often without breaking things.

For the probe request, a similar approach might by used: changing the
MAC address every X minutes, rather than using a different one for
each request.
I guess there's no harm in changing the MAC src address for every packet...

But Dan's point about iOS8 using a fixed MAC address on association was something I had heard might be the case - which may be a compromise that Apple had to make at this stage. I think that once a device associates and starts sending much traffic (mDNS, HTTP in cleartext) it is much harder to protect the user's privacy so the benefits of changing your MAC address on association are reduced. Though that's not to say it wouldn't be beneficial in terms of privacy - the devices just need to be much more careful about what layer 3 interactions they employ - which is more the realm of IETF and others.

  I think there is a benefit to associating with a random MAC address. The STA just has to stick
to it for the duration of its (re)association to the ESS. By changing back to the machine MAC
address to associate it allows for a consistent identity to be tracked over time and over location.
Like I said, I think Apple's randomized MAC address scheme is merely to make it harder for 
people to provide location services to iOS devices without doing it Apple's way. They will gladly
accept any "privacy" accolades thrown their way but I think their motive was anything but.

  Attached is a presentation I made to IEEE 802.11 back in March. It went over like a lead
balloon but that was not due to any technical issues, it was pure politics.

  You're right about information exposed above L2 is more the realm of the IETF and others
but if we don't decouple MAC address from that information above L2 then we will still
provide information that could link a person to a whole bunch of privacy-enhanced blobs
of data at L3 and above. And vice versa, merely randomizing a MAC address will not be
much of a privacy solution if L3 and above is not privacy-enhanced.

  regards,

  Dan.

Piers

My two cents.
Regards,
Mathieu Cunche, PhD
Associate Professor
University of Lyon | INSA-Lyon, CITI Lab. | Inria Privatics
Email: mathieu.cunche@xxxxxxxx | Web: mathieu.cunche.free.fr
Phone: (+33) 4 72 43 73 15
  In any event, I agree on the "low-hanging fruit" point. Changing MAC addresses during an association,
or during a BSS transition will screw up lots of stuff. We should not bite off more than we can chew and
this low-hanging fruit would be an appropriate morsel.
  regards,
  Dan.
Changing during an association clearly would require changes in both AP
and STA behavior and the need for a 802 specification.
Such an approach (dubbed 'SlyFi') was detailed in a research paper I mentioned in my Tech Plenary talk:
"Improving Wireless Privacy with an Identifier-Free Link Layer Protocol", MobiSys, 2008:
the scenarios where the MAC
of the AP may change and the scenarios where the MAC of the terminal
changes while moving to an AP of the same network.
Yes, multiple APs (ESS) needs to be a use case.
I imagine that facilities like frame forwarding in an ESS may be hampered by a randomly changing MAC address, unless it can be appropriately coordinated with the DS.
Each of the
scenarios will have different implications most probably.
I also think that for the end user this will mean a short
disconnection but if its IP address does not change (this might not be
true in case SLAAC or DHCP with assigned IPs is used), everything will
continue working automagically.
IP address continuity should be a requirement …
Yes I agree this is should be the case - the IP address is something that is already independent of the device. Although some systems (e.g. DHCP) can base their IP address assignment decision upon the link layer address. There there are also protocols around network attachment - such as DNA (RFC4436, RFC6059) which also utilise link layer addresses. I think these protocols (and probably others) need a privacy review.
Cheers,
Piers
My two cents
Cheap price for a good set of scenarios …
Paul
Br
Antonio
On Wed, Sep 3, 2014 at 5:51 PM, Paul Lambert <paul@xxxxxxxxxxx<mailto:paul@xxxxxxxxxxx>> wrote:
On 9/3/14, 7:48 AM, "Antonio de la Oliva" <aoliva@xxxxxxxxxx<mailto:aoliva@xxxxxxxxxx>> wrote:
Dear all,
this can also be done by CLI on Linux and by the GUI in Windows, so it
is a well known feature. I agree that manual modification is not the
best option for the purposes of this group.
Yes - but Bob was discussing a possible IETF trial of some sort.  It
would
be interesting to document the impact of address changes in various
environments.
While the call was running, I tried changing MAC address.  I lost
connection to Wi-Fi and the web sharing, but it did reconnect.  I
suspect
that this will generally be the case for WPA2-Perssonal implementations.
WPA2-Enterprise (EAP based) authentication will be problematic I suspect
when MAC address changes occur during a session.  APs would either need
to
be participants in the address change process (e.g. BT example), or the
changes need to be per BSS/ESS.
Paul
Br
Antonio
On Wed, Sep 3, 2014 at 4:46 PM, Paul Lambert <paul@xxxxxxxxxxx<mailto:paul@xxxxxxxxxxx>> wrote:
On the topic of testing the impact of randomization of MAC addresses:
Apple computers can readily change the MAC address using the command
line.
Scripts and tools are available to facilitate this capability.  For
example,
the SpoofMAC script works pretty well for manual changes and can be
set
to
run on every start-up.
Manual setting or per boot setting is not the optimal approach.  MAC
address
changes should be integrated into the connection software (e.g. Wi-Fi
supplicant) to change address in coordination with association to
particular
BSS/ESS.
Paul
Date: Tuesday, September 2, 2014 at 1:37 PM
Subject: September 3 - Teleconference details
Dear all,
Please find below the call-in details for tomorrow¹s teleconference.
Best regards,
Juan Carlos
-------------------------------------------------------
Agenda
-------------------------------------------------------
- Welcome
- Chair's slides
- IEEE Slides
- Group's Introduction
- Technical Topics
(1) Privacy Issues at Link Layer
(2) Threat Model for Privacy at Link Layer
(3) Proposals regarding functionalities in IEEE 802 protocols to
improve
Privacy
(4) Proposals regarding measuring levels of Privacy on Internet
protocols
(5) Other
- Next Steps
-------------------------------------------------------
Meeting information
-------------------------------------------------------
Topic: EC Priv Recomm SG #1
Date: Wednesday, September 3, 2014
Time: 10:00 am, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 740 470 465
Meeting Password: privrecsg
-------------------------------------------------------
To start or join the online meeting
-------------------------------------------------------
Go to
3d
a2e6bfd
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call
back.
Alternatively, you can call:
Call-in number (Premiere): 1-719-867-1571  (US/Canada)
Show global numbers:
=1
719-867-1571
Attendee access code: 542167
-------------------------------------------------------
For assistance
-------------------------------------------------------
2. On the left navigation bar, click "Support".
To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
f9
792354a
To check whether you have the appropriate players installed for UCF
(Universal Communications Format) rich media files, go to
CCM:+17198671571x5421670#
IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio
and any documents and other materials exchanged or viewed during the
session
to be recorded. You should inform all meeting attendees prior to
recording
if you intend to record the meeting. Please note that any such
recordings
may be subject to discovery in the event of litigation.
--
Antonio de la Oliva
Assistant Professor
Telematics Department
Universidad Carlos III de Madrid
Phone: +34 91 624 8803
Fax:   +34 91 624 8749
--
Antonio de la Oliva
Assistant Professor
Telematics Department
Universidad Carlos III de Madrid
Phone: +34 91 624 8803
Fax:   +34 91 624 8749

Attachment: 11-14-0430-02-000m-random-macs-for-privacy.pptx
Description: 11-14-0430-02-000m-random-macs-for-privacy.pptx