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.