Project: IEEE 802 EC Privacy Recommendation Study Group Dec 2014 Project: IEEE 802 EC Privacy Recommendation Study Group Submission Title: Secure Moderated Random MAC Addresses Date Submitted: Dec 10, 2014 Source: Robert Moskowitz, Verizon Address 1000 Bent Creek Blvd, MechanicsBurg, PA, USA Voice:+1 (248) 968-9809, e-mail: rgm@labs.htt-consult.com Re: KMP TG9 Closing Report for Sept 2014 Session 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. Robert Moskowitz, Verizon

Secure Moderated Random MAC Addresses Dec 2014 Secure Moderated Random MAC Addresses Conference Call Dec 10, 2014 Robert Moskowitz, Verizon

Dec 2014 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 A moderator should introduce yet another attack point Robert Moskowitz, Verizon

A simple Moderator Protocol Dec 2014 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 Robert Moskowitz, Verizon

And crypto signing of request Dec 2014 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 But what design won't add yet another attack point? Replay attacks for signed requests Resource attacks against the crypto operations Probably more Robert Moskowitz, Verizon

A simple secure exchange Dec 2014 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 Including ECDH key Moderator ACK/NAKs request MICed with ECDH shared secret Fits well within 802.11 BEACON/ASSOCIATE mechanism Fits well within DHCP Devil is in the Details Robert Moskowitz, Verizon

Dec 2014 DISCUSSION Robert Moskowitz, Verizon