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

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

Hi all,

 

I think the email subject here is getting a little staled. However, in the email discussion there have been a number of very good points that will be useful for an eventual report/recommendation from the Group. Let me try to summarize the points using the topics from the Call for Contributions:

 

1.       Privacy Issues at Link Layer

o   Use of long lasting (e.g. globally unique) identifiers

§  User’s MAC address

§  SSID history broadcast with active probing (NOTE: not much discussion so far, but I think it should be added)

2.       Threat model for Privacy at Link Layer

o   Over the air privacy against passive attackers (i.e. observers)

3.       Proposals regarding functionalities in IEEE 802 protocols to improve privacy

o   MAC address randomization

§  During scanning phase (Probe REQ/RSP)

§  During active session

o   Bluetooth Privacy feature (see DCN privecsg-14-0005-01)

4.       Proposals regarding measuring levels of Privacy on Internet protocols

o   (NOTE: nothing so far)

5.       Implications of MAC address changes on

o   Collisions

o   DHCP states

o   IPv6 addressing

o   ARP/ND

o   Key derivation

o   SDN tables

o   Bridging/routing tables

o   Power utilization

o   Applications

 

(Have I missed any? – Please add/correct)

 

It is probably worth having an email thread for a discussion on some of these topics separately, so that we can later on produce some useful documentation.

 

I’ll start with one and provide some feedback to the group about the discussions during the presentations I recently gave to the 802.1/802.3 WGs.

 

Regards,

 

Juan Carlos

 

 

 

From: Lee, Soo Bum [mailto:soobuml@xxxxxxxxxxxxxxxx]
Sent: Thursday, September 11, 2014 12:43 PM
To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-Privacy] September 3 - Teleconference details

 

Hello,

 

I mostly agree with Dan’s comments. Just as a minor addition, I think there are some privacy issues specific to WLAN, i.e., over the air privacy against passive attackers. Improving privacy only for the wireless part seems to have great impact considering the ever increasing number of wireless devices. Furthermore, WLAN air interface privacy can be considered separately from DS and the upper-layer protocols to some extent.

 

Best wishes,

Soo Bum

 

From: Dan Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 11, 2014 8:57 AM
To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
Subject: 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