Download Report

Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
Project: IEEE 802 EC Privacy Recommendation Study Group
Submission Title: Secure Moderated Random MAC Addresses
Date Submitted: Jan 13, 2015
Source: Robert Moskowitz, HTT Consulting
Address: Oak Park, MI, USA
Voice:+1 (248) 968-9809, e-mail: [email protected]
Re: Privacy for MAC Addresses
Abstract: Secure Moderated Random MAC Addresses
Purpose: To Securely Moderate Random MAC Addresses
Notice: This document has been prepared to assist the IEEE P802 EC. It is offered as a basis for
discussion and is not binding on the contributing individual(s) or organization(s). The material in this
document is subject to change in form and content after further study. The contributor(s) reserve(s) the right
to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE
and may be made publicly available by P802 EC.
Submission
Slide 1
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
Secure Moderated Random MAC
Addresses
Atlanta, GA
Jan 13, 2015
Submission
Slide 2
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
Problem Statement


Free for all in Local Scope MAC address space
Randomized address selection has no method of
dealing with collisions
–

Even if full 46 bits remain available
802 architecture calls out for use of an address
moderator if Local Scope is used
–
Submission
A moderator could introduce yet another attack
point
Slide 3
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
A simple Moderator Protocol

Client informs moderator of MAC address it will use

Moderator either accepts or rejects
–
What constitutes a reject
•
How does the moderator know?

No way for Moderator to recognize duplicates

Sounds a bit like DHCP
Submission
Slide 4
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
An Enhanced Moderator Protocol

Client informs moderator of MAC address it will use
–


Includes a 128 bit random 'ID'
Moderator either accepts or rejects
–
If different ID from current assigned for MAC
address
–
If repeat ID for a different MAC address?
Open to ID cloning attack against stable ID use
Submission
–
OK in completely random MAC use
–
Issue for permanent MAC use
Slide 5
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
And crypto signing of request


The client can digitally sign the address request
The moderator can now recognize different clients
using the same address and reject the late-comer

Protect against cloning use

How do you build up a trusted signing infrastructure?

But what design won't add yet another attack point?
Submission
–
Replay attacks for signed requests
–
Resource attacks against the crypto operations
–
Probably more
Slide 6
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
A simple secure exchange

Use ECDH

Moderator BEACONs its ECDH key

Client derives address from its ECDH key
–

Client MICs its request with ECDH shared secret
–

May be ephemeral or long-lived, depending on goal
Including ECDH key
Moderator ACK/NAKs request
–
MICed witgh ECDH shared secret

Fits well within 802.11 BEACON/ASSOCIATE

Fits well within DHCP

Devil is in the Details
Submission
Slide 7
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
Summary of Moderator Methods



The Moderator only receives requested MAC address
–
No management of duplicate MAC addresses
–
DHCP today
ID accompanies MAC in request
–
Moderator can recognize duplicates
–
Works well enough for AdHoc only MAC use
MAC request cryptographically signed
–

Very problematic in terms of costs vs value
MAC address cryptographically generated
–
Submission
Balances AdHoc and long-term use of MAC
address
Slide 8
Robert Moskowitz, HTT Consulting
Jan 2015
doc.: IEEE privecsg-14-0026-01-Rnd-Modr-MAC-Addr
DISCUSSION
Submission
Slide 9
Robert Moskowitz, HTT Consulting