Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol
On 11/6/14, 11:57 AM, "Robert Moskowitz" <rgm@xxxxxxxxxxxxxxxxxxxx> wrote:
>On 11/06/2014 01:03 PM, Christian Huitema wrote:
>>> 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?
>
>There is a high degree of commonality in these protocols. In part as
>there are only a few ways to do them right. Plus a few of us have
>worked on more than one. Lots of cross knowledge transfer.
I¹d disagree a little Š first the above key exchange is not quite right,
I¹d suggest a blinded more static key usage (per EMV specification, plus a
MAC blinding nonce).
802.1x/EAP is problem in the 802.11 security architecture. Doing good
peer-to-peer authentication is not well modeled hy the client/AP/AAA
three-way model of 802.1x and EAP.
It would be much better to use pre-association frames for a key exchange.
For new P2P authentication, there are multiple options:
- action frames (my preference)
- probe req/rsp (easy, but include legacy cruft and not efficient)
- authenticate and/or associate frames
- above per 802.11ai (existing, but rigidly in it¹s own model of
connectivity and may not map well to MAC address change requirements)
WPA2 is in several parts Š the 802.1x setup is an issue (IMO) per above,
but is not necessary and easily left out. The WPA2 4-way handshake steps
are required to get nonces for the CCM/GCM Tk. However, the YK could be
more directly estblished by a stream-lined authentication exchange (e.g.
802.11ai). Finally, the broadcast Group Key is shared during the 4-way
exchange. This is a longer discussion Š since broadcast keys in a P2P
environment need to be device unique.
Paul
>
>>
>>> 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.
>
>First not only is there no reason to care what MACaddr is used for
>PROBES, Apple already uses a random one to not leak tackable information
>about the devices. Use ANY MACaddr you want. Could be a problem if
>there is a collision with an address that is already used and secured.
>> 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.
>
>If the address is only used for PROBES, just dream one up (local scope
>of course) and use it. This need not be the one you plan on actually
>using for the ASSOCIATION.