Subject: [6tisch-security] On peer-to-peer authentication ...

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Nov 2014 09:31:11 +0000

Cheers,

Pascal

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]] 
Sent: vendredi 21 novembre 2014 22:28
To: [email-masked]
Subject: Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol

On 11/6/14, 11:57 AM, "Robert Moskowitz" <[email-masked]> 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.