Re: [STDS-802-Privacy] September 3 - Teleconference details
Another SLyFi at:
https://mentor.ieee.org/802.11/dcn/08/11-08-1022-00-0wng-slyfi-enhancing-80211-privacy.ppt
Seems like a bibliography of past work would be interesting ...
]-----Original Message-----
]From: Piers O'Hanlon [mailto:piers.ohanlon@xxxxxxxxxxxx]
]Sent: Wednesday, September 10, 2014 9:34 AM
]To: Paul Lambert
]Cc: Antonio de la Oliva; Zuniga, Juan Carlos; stds-802-privacy@xxxxxxxx
]Subject: Re: 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=m3817347fdb37efa239
]>>>>> a354f
]>>>>> 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=m272e6fe525b4b6d87d
]>>>>> 2af77
]>>>>> 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