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

Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol

On 11/06/2014 05:17 PM, Stephens, Adrian P wrote:

A duplicate address creates minor issues in the wireless LAN.
It may cause multiple STAs to generate an Ack to the Probe response.
The collided Acks may corrupt each other,  causing the Probe response to
be retried.

Net result,  a slight waste of time.   But given the probability is low,
I don't think we care.
It has been a long time since I plowed through this in 802.11, but I kind of thought it was like that.
While first doing the passive scan before the active scan, the device would learn some of the existing MACs and could easily avoid any it heard. 


Of course,  post association, we would care.
And I think this is easy to design/implement to avoid problems. Of course I am highly biased. 



Best Regards,
Adrian P STEPHENS Tel: +44 (1793) 404825 (office) 
Tel: +44 (7920) 084 900 (mobile,  UK)
Tel: +1 (408) 2397485 (mobile, USA)
---------------------------------------------- 
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

-----Original Message-----
From: Andrew Myles (amyles) [mailto:amyles@xxxxxxxxx]
Sent: Thursday, November 06, 2014 5:13 PM
To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol

G'day all

Just another thought ...

While a STA is Probing, does it really matter if a duplicate address is used? I suspect that either the duplicate address will not cause any problems, or any issues can be mitigated.

I suspect the same is true for a STA using GAS, but I have not considered this case in detail.

Andrew





-----Original Message-----
From: Christian Huitema [mailto:huitema@xxxxxxxxxxxxx]
Sent: Friday, 7 November 2014 6:04 AM
To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol


Every participating device has a MAC entity Identity consisting of the public key of a ECDH keypair.  A hash of this key into a 128 bit value is the MAC entity Identifier, much like the HIT in HIP.  A hash with a nonce will be used to create the actual MACaddr used by the device.  For privacy purposes, the ECDH keypair are ephemeral, a device can precompute a number of these and have them ready to use at will.  For collision avoidance a device must be ready to use a different Identity or nonce to present a different MACaddr.

Curious how that meshes with 802.1x/EAP, or with WPA2. Did you research that?


At linkup time, a device will listen for these broadcasts, use the public key therein along with its Identity key and a nonce to construct a shared secret.  This secret will be used to MIC a packet to the mediator that will contain the devices:  MACaddr, Nonce, Identifier, and Identity.  If this is a new MACaddr for the mediator it would reply with an ACCEPT MICed message.  If there is a collision, it will REJECT, causing the device to select a new MACaddr and try again.

What if there is no link-up time, as in for example Wi-Fi probes? When scanning for available networks, Wi-Fi devices send probe packets to elicit responses from any access point that would be present. These packets are sent infrequently, maybe every few minutes, while the device is not connected to any network and is in fact moving between networks. Uniqueness in one of these networks is not a guarantee of uniqueness in the next one.

This scanning traffic is a well known target of tracking systems. Protecting it is a high priority. That's the first application of randomized MAC addresses. And for that application, the simplest solution is statistical uniqueness through large enough random numbers.

-- Christian Huitema