Re: [STDS-802-Privacy] September 3 - Teleconference details
On 3 Sep 2014, at 17:43, Paul Lambert wrote:
> On 9/3/14, 9:15 AM, "Antonio de la Oliva" <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.
> 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:
http://www.cs.washington.edu/research/security/mobisys08-slyfi.pdf
>> 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> wrote:
>>>
>>>
>>> On 9/3/14, 7:48 AM, "Antonio de la Oliva" <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> 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.
>>>>>
>>>>> https://github.com/feross/SpoofMAC
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> From: <Zuniga>, Juan Carlos <JuanCarlos.Zuniga@xxxxxxxxxxxxxxxx>
>>>>> Date: Tuesday, September 2, 2014 at 1:37 PM
>>>>> To: "stds-802-privacy@xxxxxxxx" <stds-802-privacy@xxxxxxxx>
>>>>> 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
>>>>>
>>>>> https://premconf.webex.com/premconf/j.php?MTID=m3817347fdb37efa239a354f
>>>>> 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:
>>>>>
>>>>> https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=542167&num=1&num2
>>>>> =1
>>>>> 719-867-1571
>>>>> Attendee access code: 542167
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> For assistance
>>>>> -------------------------------------------------------
>>>>> 1. Go to https://premconf.webex.com/premconf/mc
>>>>> 2. On the left navigation bar, click "Support".
>>>>> To add this meeting to your calendar program (for example Microsoft
>>>>> Outlook), click this link:
>>>>>
>>>>> https://premconf.webex.com/premconf/j.php?MTID=m272e6fe525b4b6d87d2af77
>>>>> f9
>>>>> 792354a
>>>>>
>>>>> To check whether you have the appropriate players installed for UCF
>>>>> (Universal Communications Format) rich media files, go to
>>>>> https://premconf.webex.com/premconf/systemdiagnosis.php.
>>>>>
>>>>> http://www.webex.com
>>>>>
>>>>> 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
>>>> E-mail: aoliva@xxxxxxxxxx
>>>> Phone: +34 91 624 8803
>>>> Fax: +34 91 624 8749
>>>
>>
>>
>>
>> --
>> Antonio de la Oliva
>> Assistant Professor
>> Telematics Department
>> Universidad Carlos III de Madrid
>> E-mail: aoliva@xxxxxxxxxx
>> Phone: +34 91 624 8803
>> Fax: +34 91 624 8749