doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 1 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) , 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.

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 2 Secure Moderated Random MAC Addresses Atlanta, GA Jan 13, 2015

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 3 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 could introduce yet another attack point

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 4 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

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 5 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 – OK in completely random MAC use – Issue for permanent MAC use

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 6 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? – Replay attacks for signed requests – Resource attacks against the crypto operations – Probably more

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 7 A simple secure exchange Use ECDH Moderator BEACONs its ECDH key Client derives address from its ECDH key – May be ephemeral or long-lived, depending on goal Client MICs its request with ECDH shared secret – Including ECDH key Moderator ACK/NAKs request – MICed witgh ECDH shared secret Fits well within BEACON/ASSOCIATE Fits well within DHCP Devil is in the Details

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 8 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 – Balances AdHoc and long-term use of MAC address

doc.: IEEE privecsg Rnd-Modr-MAC-Addr Submission Jan 2015 Robert Moskowitz, HTT Consulting Slide 9 DISCUSSION