Randomized and Changing MAC Address state of affairs
draft-ietf-madinas-mac-address-randomization-12
| Document | Type | Active Internet-Draft (madinas WG) | |
|---|---|---|---|
| Authors | Juan-Carlos Zúñiga , Carlos J. Bernardos , Amelia Andersdotter | ||
| Last updated | 2024-02-28 | ||
| Replaces | draft-zuniga-madinas-mac-address-randomization, draft-zuniga-mac-address-randomization | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | Peter E. Yee | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | peter@akayla.com |
draft-ietf-madinas-mac-address-randomization-12
MADINAS JC. Zuniga
Internet-Draft CISCO
Intended status: Informational CJ. Bernardos, Ed.
Expires: 31 August 2024 UC3M
A. Andersdotter
Safespring AB
28 February 2024
Randomized and Changing MAC Address state of affairs
draft-ietf-madinas-mac-address-randomization-12
Abstract
Users are becoming more aware that their activity over the Internet
leaves a vast digital footprint, that communications might not always
be properly secured, and that their location and actions can be
tracked. One of the main factors that eases tracking users is the
wide use of long-lasting, and sometimes persistent, identifiers at
various protocol layers. This document focuses on MAC addresses.
There have been several initiatives within the IETF and the IEEE 802
standards committees to overcome some of these privacy issues. This
document provides an overview of these activities to help
coordinating standardization activities in these bodies.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zuniga, et al. Expires 31 August 2024 [Page 1]
Internet-Draft Randomized and Changing MAC Address February 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. MAC address usage . . . . . . . . . . . . . . . . . . . . 3
2.2. MAC address randomization . . . . . . . . . . . . . . . . 4
2.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE
802 meetings . . . . . . . . . . . . . . . . . . . . . . 5
3. Randomized and Changing MAC addresses activities at the IEEE
802 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Recent MAC randomization-related activities at the WBA . . . 7
5. MAC randomization in IETF Protocol Standards . . . . . . . . 8
6. A taxonomy of MAC address selection policies . . . . . . . . 9
6.1. Per-Vendor OUI MAC address (PVOM) . . . . . . . . . . . . 10
6.2. Per-Device Generated MAC address (PDGM) . . . . . . . . . 10
6.3. Per-Boot Generated MAC address (PBGM) . . . . . . . . . . 10
6.4. Per-Network Generated MAC address (PNGM) . . . . . . . . 10
6.5. Per-Period Generated MAC address (PPGM) . . . . . . . . . 11
6.6. Per-Session Generated MAC address (PSGM) . . . . . . . . 11
7. OS current practices . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Internet privacy is becoming a huge concern, as more and more devices
are getting directly (e.g., via Wi-Fi) or indirectly (e.g., via a
smartphone using Bluetooth) connected to the Internet. This
ubiquitous connectivity, together with the lack of proper education
about privacy make it very easy to track/monitor the location of
users and/or eavesdrop their physical and online activities. This is
due to many factors, such as the vast digital footprint that users
leave on the Internet with or without their consent, for instance
sharing information on social networks, cookies used by browsers and
servers for various reasons, connectivity logs that allow tracking of
a user's Layer-2 (L2/MAC) or Layer-3 (L3) address, web trackers,
Zuniga, et al. Expires 31 August 2024 [Page 2]
Internet-Draft Randomized and Changing MAC Address February 2024
etc.; and/or the weak (or even null in some cases) authentication and
encryption mechanisms used to secure communications.
This privacy concern affects all layers of the protocol stack, from
the lower layers involved in the access to the network (e.g., the
MAC/Layer-2 and Layer-3 addresses can be used to obtain the location
of a user) to higher layer protocol identifiers and user applications
[wifi_internet_privacy]. In particular, IEEE 802 MAC addresses have
historically been an easy target for tracking users [wifi_tracking].
There have been several initiatives at the IETF and the IEEE 802
standards committees to overcome some of these privacy issues. This
document provides an overview of these activities to help
coordinating standardization activities within these bodies.
2. Background
2.1. MAC address usage
Most mobile devices used today are WLAN enabled (i.e., they are
equipped with an IEEE 802.11 wireless local area network interface).
Wi-Fi interfaces, as any other kind of IEEE 802-based network
interface, like Ethernet (i.e., IEEE 802.3) have a Layer-2 address
also referred to as MAC address, which can be seen by anybody who can
receive the radio signal transmitted by the network interface. The
format of these addresses is shown in Figure 1.
+--------+--------+---------+--------+--------+---------+
| Organizationally Unique | Network Interface |
| Identifier (OUI) | Controller (NIC) Specific |
+--------+--------+---------+--------+--------+---------+
/ \
/ \
/ \ b0 (I/G bit):
/ \ 0: unicast
/ \ 1: multicast
/ \
/ \ b1 (U/L bit):
+--+--+--+--+--+--+--+--+ 0: globally unique (OUI enforced)
|b7|b6|b5|b4|b3|b2|b1|b0| 1: locally administered
+--+--+--+--+--+--+--+--+
Figure 1: IEEE 802 MAC Address Format
MAC addresses can either be universally administered or locally
administered. Universally administered and locally administered
addresses are distinguished by setting the second-least-significant
bit of the most significant byte of the address (the U/L bit).
Zuniga, et al. Expires 31 August 2024 [Page 3]
Internet-Draft Randomized and Changing MAC Address February 2024
A universally administered address is uniquely assigned to a device
by its manufacturer. Most physical devices are provided with a
universally administered address, which is composed of two parts: (i)
the Organizationally Unique Identifier (OUI), which are the first
three octets in transmission order and identify the organization that
issued the identifier, and (ii) Network Interface Controller (NIC)
Specific, which are the following three octets, assigned by the
organization that manufactured the NIC, in such a way that the
resulting MAC address is globally unique.
Locally administered addresses override the burned-in address, and
they can either be set-up by the network administrator, or by the
Operating System (OS) of the device to which the address pertains.
However, as explained in further sections of this document, there are
new initiatives at the IEEE 802 and other organizations to specify
ways in which these locally administered addresses should be
assigned, depending on the use case.
2.2. MAC address randomization
Since universally administered MAC addresses are by definition
globally-unique, when a device uses this MAC address to transmit data
-especially over the air- it is relatively easy to track this device
by simple medium observation. Since a device is usually directly
associated to an individual, this poses a privacy concern
[link_layer_privacy].
MAC addresses can be easily observed by a third party, such as a
passive device listening to communications in the same network. In
an 802.11 network, a station exposes its MAC address in two different
situations:
* While actively scanning for available networks, the MAC address is
used in the Probe Request frames sent by the device (aka IEEE
802.11 STA).
* Once associated to a given Access Point (AP), the MAC address is
used in frame transmission and reception, as one of the addresses
used in the address fields of an IEEE 802.11 frame.
Zuniga, et al. Expires 31 August 2024 [Page 4]
Internet-Draft Randomized and Changing MAC Address February 2024
One way to overcome this privacy concern is by using randomly
generated MAC addresses. The IEEE 802 addressing includes one bit to
specify if the hardware address is locally or globally administered.
This allows generating local addresses without the need of any global
coordination mechanism to ensure that the generated address is still
unique within the local network. This feature can be used to
generate random addresses, which decouple the globally-unique
identifier from the device and therefore make it more difficult to
track a user device from its MAC/L2 address
[enhancing_location_privacy].
Note that there are reports [contact_tracing_paper] of some mobile
Operating Systems (OSes) reporting persistently (every 20 minutes or
so) on MAC addresses (among other information), which would defeat
MAC address randomization. While these practices might have changed
by now, it is important to highlight that privacy preserving
techniques should be conducted considering all layers of the protocol
stack.
2.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802
meetings
As an outcome to the STRINT W3C/IAB Workshop [strint], a tutorial on
"Pervasive Surveillance of the Internet - Designing Privacy into
Internet Protocols" was given at the IEEE 802 Plenary meeting in San
Diego [privacy_tutorial] in July of 2014. The tutorial provided an
update on the recent developments regarding Internet privacy, the
actions undertaken by other SDOs such as IETF, and guidelines that
were being followed when developing new Internet protocol
specifications (e.g., [RFC6973]). The tutorial highlighted some
privacy concerns applicable specifically to Link Layer technologies
and provided suggestions on how IEEE 802 could help addressing them.
Following the discussions and interest within the IEEE 802 community,
on 18 July 2014 the IEEE 802 Executive Committee (EC) created an IEEE
802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg].
The work and discussions from the group have generated multiple
outcomes, such as: 802E PAR: Recommended Practice for Privacy
Considerations for IEEE 802 Technologies [IEEE_802E], and the 802c
PAR: Standard for Local and Metropolitan Area Networks - Overview and
Architecture Amendment - Local Medium Access Control (MAC) Address
Usage [IEEE_802c].
In order to test the effects of MAC address randomization, trials
were conducted at the IETF and IEEE 802 meetings between November
2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in Berlin.
The purpose of the trials was to evaluate the use of MAC address
randomization from two different perspectives: (i) the effect on the
Zuniga, et al. Expires 31 August 2024 [Page 5]
Internet-Draft Randomized and Changing MAC Address February 2024
connectivity experience of the end-user, also checking if
applications and OSes were affected; and (ii) the potential impact on
the network infrastructure itself. Some of the findings were
published in [wifi_internet_privacy].
During the trials it was observed that the probability of address
duplication in a network is negligible. The trials also revealed
that other protocol identifiers (e.g., DHCP client identifier) can be
correlated and therefore be used to still track an individual.
Hence, effective privacy tools should not work in isolation at a
single layer, but they should be coordinated with other privacy
features at higher layers.
Since then, MAC randomization has further been implemented by mobile
OSes to provide better privacy for mobile phone users when connecting
to public wireless networks [privacy_ios], [privacy_windows],
[privacy_android].
3. Randomized and Changing MAC addresses activities at the IEEE 802
Practical experiences of Randomized and Changing MAC addresses (RCM)
in devices helped researchers fine-tune their understanding of
attacks against randomization mechanisms
[when_mac_randomization_fails]. At the IEEE 802.11 group these
research experiences eventually formed the basis for a specified
mechanism introduced in the IEEE 802.11aq in 2018 which randomize MAC
addresses [IEEE_802_11_aq].
More recent developments include turning on MAC randomization in
mobile OSes by default, which has an impact on the ability of network
operators to customize services [rcm_user_experience_csd].
Therefore, follow-on work in the IEEE 802.11 mapped effects of
potentially large uptake of randomized MAC identifiers on a number of
commonly offered operator services in 2019[rcm_tig_final_report]. In
the summer of 2020 this work emanated in two new standards projects
with the purpose of developing mechanisms that do not decrease user
privacy but enable an optimal user experience when the MAC address of
a device in an Extended Service Set is randomized or changes
[rcm_user_experience_par] and user privacy solutions applicable to
IEEE Std 802.11 [rcm_privacy_par].
IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017
[IEEE_802c], specifies a local MAC address space structure known as
the Structured Local Address Plan (SLAP).The SLAP designates a range
of Extended Local Identifiers (ELIs) for subassignment within a block
of addresses assigned by the IEEE Registration Authority via a
Company ID (CID). A range of local MAC addresses is designated for
Standard Assigned Identifiers (SAI) to be specified by IEEE 802
Zuniga, et al. Expires 31 August 2024 [Page 6]
Internet-Draft Randomized and Changing MAC Address February 2024
standards. Another range of local MAC addresses is designated for
Administratively Assigned Identifiers (AAI) subject to assignment by
a network administrator.
"IEEE Std 802E-2020: Recommended Practice for Privacy Considerations
for IEEE 802 Technologies" [IEEE_802E] recommends the use of
temporary and transient identifiers if there are no compelling
reasons for a newly introduced identifier to be permanent. This
recommendation is part of the basis for the review of user privacy
solutions for IEEE Std 802.11 (aka Wi-Fi) devices as part of the RCM
[rcm_privacy_csd] efforts. Annex T of IEEE Std 802.1AEdk-2023: MAC
Privacy Protection [IEEE802.1AEdk-2023] discusses privacy
considerations in bridged networks.
As per 2024, two task groups in IEEE 802.11 are dealing with issues
related to RCM:
* The IEEE 802.11bh task group, looking at mitigating the
repercussions that RCM creates on 802.11 networks and related
services, and
* The IEEE 802.11bi task group, which is chartered to define
modifications to the IEEE Std 802.11 medium access control (MAC)
specification to specify new mechanisms that address and improve
user privacy.
4. Recent MAC randomization-related activities at the WBA
At the Wireless Broadband Alliance (WBA), the Testing and
Interoperability Work Group has been looking at the issues related to
MAC address randomization and has identified a list of potential
impacts of these changes to existing systems and solutions, mainly
related to Wi-Fi identification.
As part of this work, WBA has documented a set of use cases that a
Wi-Fi Identification Standard should address in order to scale and
achieve longer term sustainability of deployed services. A first
version of this document has been liaised with the IETF as part of
the MAC Address Device Identification for Network and Application
Services (MADINAS) activities through the "Wi-Fi Identification In a
post MAC Randomization Era v1.0" paper [wba_paper].
Zuniga, et al. Expires 31 August 2024 [Page 7]
Internet-Draft Randomized and Changing MAC Address February 2024
5. MAC randomization in IETF Protocol Standards
[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
IPv6, which typically results in hosts configuring one or more
"stable" addresses composed of a network prefix advertised by a local
router, and an Interface Identifier (IID). [RFC8064] formally
updated the original IPv6 IID selection mechanism to avoid generating
the IID from the MAC address of the interface (via EUI64), as this
potentially allowed for tracking of a device at L3. Additionally,
the prefix part of an IP address provides meaningful insights of the
physical location of the device in general, which together with the
MAC address-based IID, made it easier to perform global device
tracking.
[RFC8981] identifies and describes the privacy issues associated with
embedding MAC stable addressing information into the IPv6 addresses
(as part of the IID). It describes an extension to IPv6 Stateless
Address Autoconfiguration that causes hosts to generate temporary
addresses with randomized interface identifiers for each prefix
advertised with autoconfiguration enabled. Changing addresses over
time limits the window of time during which eavesdroppers and other
information collectors may trivially perform address-based network-
activity correlation when the same address is employed for multiple
transactions by the same host. Additionally, it reduces the window
of exposure of a host as being accessible via an address that becomes
revealed as a result of active communication. These temporary
addresses are meant to be used for a short period of time (hours to
days) and would then be deprecated. Deprecated addresses can
continue to be used for already established connections, but are not
used to initiate new connections. New temporary addresses are
generated periodically to replace temporary addresses that expire.
In order to do so, a node produces a sequence of temporary global
scope addresses from a sequence of interface identifiers that appear
to be random in the sense that it is difficult for an outside
observer to predict a future address (or identifier) based on a
current one, and it is difficult to determine previous addresses (or
identifiers) knowing only the present one. Temporary addresses
should not be used by applications that listen for incoming
connections (as these are supposed to be waiting on permanent/well-
known identifiers). If a node changes network and comes back to a
previously visited one, the temporary addresses that the node would
use will be different, and this might be an issue in certain networks
where addresses are used for operational purposes (e.g., filtering or
authentication). [RFC7217], summarized next, partially addresses the
problems aforementioned.
Zuniga, et al. Expires 31 August 2024 [Page 8]
Internet-Draft Randomized and Changing MAC Address February 2024
[RFC7217] describes a method to generate Interface Identifiers that
are stable for each network interface within each subnet, but that
change as a host moves from one network to another. This method
enables keeping the "stability" properties of the Interface
Identifiers specified in [RFC4291], while still mitigating address-
scanning attacks and preventing correlation of the activities of a
host as it moves from one network to another. The method defined to
generate the IPv6 IID is based on computing a hash function which
takes as input information that is stable and associated to the
interface (e.g., a local interface identifier), stable information
associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6
prefix, and a secret key, plus some other additional information.
This basically ensures that a different IID is generated when any of
the input fields changes (such as the network or the prefix), but
that the IID is the same within each subnet.
Currently, [RFC8064] recommends nodes to implement [RFC7217] as the
default scheme for generating stable IPv6 addresses with SLAAC, to
mitigate the privacy threats posed by the use of MAC-derived IIDs.
In addition to the former documents, [RFC8947] proposes an extension
to DHCPv6 that allows a scalable approach to link-layer address
assignments where preassigned link-layer address assignments (such as
by a manufacturer) are not possible or unnecessary. [RFC8948]
proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or
a DHCPv6 relay to indicate a preferred SLAP quadrant to the server,
so that the server may allocate MAC addresses in the quadrant
requested by the relay or client.
Not only MAC and IP addresses can be used for tracking purposes.
Some DHCP options carry unique identifiers. These identifiers can
enable device tracking even if the device administrator takes care of
randomizing other potential identifications like link-layer addresses
or IPv6 addresses. [RFC7844] introduces anonymity profiles, designed
for clients that wish to remain anonymous to the visited network.
The profiles provide guidelines on the composition of DHCP or DHCPv6
messages, designed to minimize disclosure of identifying information.
[RFC7844] also indicates that the link-layer address, IP address, and
DHCP identifier shall evolve in synchrony.
6. A taxonomy of MAC address selection policies
This section documents different policies for MAC address selection.
Some OSes might use combination of multiple of these policies.
Note about the used naming convention: the "M" in MAC is included in
the acronym, but not the "A" from address. This allows one to talk
about a PVOM Address, or PNGM Address.
Zuniga, et al. Expires 31 August 2024 [Page 9]
Internet-Draft Randomized and Changing MAC Address February 2024
The names are all in the form for per-period-of-time-selection.
6.1. Per-Vendor OUI MAC address (PVOM)
This form of MAC address selection is the historical default.
The vendor obtains an Organizationally Unique Identifier (OUI) from
the IEEE. This has been a 24-bit prefix (including two upper bits
which are set specifically) that is assigned to the vendor. The
vendor generates a unique 24-bit value for the lower 24-bits, forming
the 48-bit MAC address. It has not been unusual for the 24-bit value
to be taken as an incrementing counter, assigned at the factory, and
burnt into non-volatile storage.
Note that 802.15.4 use 64-bit MAC addresses, and the IEEE assigns
32-bit prefixes. The IEEE has indicated that there may be a future
Ethernet specification using 64-bit MAC addresses.
6.2. Per-Device Generated MAC address (PDGM)
This form of MAC address is randomly generated by the device, usually
upon first boot. The resulting MAC address is stored in non-volatile
storage and is used for the rest of the device lifetime.
6.3. Per-Boot Generated MAC address (PBGM)
This form of MAC address is randomly generated by the device, each
time the device is booted. The resulting MAC address is *not* stored
in non-volatile storage. It does not persist across power cycles.
This case may sometimes be a PDGM where the non-volatile storage is
no longer functional (or has failed).
6.4. Per-Network Generated MAC address (PNGM)
This form of MAC address is generated each time a new network
attachment is created.
This is typically used with WiFi (802.11) networks where the network
is identified by an SSID Name. The generated address is stored on
non-volatile storage, indexed by the SSID. Each time the device
returns to a network with the same SSID, the device uses the saved
MAC address.
It is possible to use PNGM for wired Ethernet connections through
some passive observation of network traffic, such as STP, LLDP, DHCP
or Router Advertisements to determine which network has been
attached.
Zuniga, et al. Expires 31 August 2024 [Page 10]
Internet-Draft Randomized and Changing MAC Address February 2024
6.5. Per-Period Generated MAC address (PPGM)
This form of MAC address is generated periodically. Typical numbers
are around every twelve hours. Like PNGM, it is used primarily with
WiFi (802.11).
When the MAC address changes, the station disconnects from the
current session and reconnects using the new MAC address. This will
involve a new WPA/802.1x session: new EAP, TLS, etc. negotiations. A
new DHCP, Router-Advertisement will be done. TBD: it is unclear if
any TLS session-resumption ticket (used by EAP-TLS) can or should be
retained across a change of the MAC address.
If DHCP is used, then a new DUID is generated so as to not link to
the previous connection, and the result is usually new IP addresses
allocated.
6.6. Per-Session Generated MAC address (PSGM)
This form of MAC address is generated on a per session basis. Like
PNGM, it is used primarily with WiFi (802.11).
Since the address changes only when a new session is established,
there is no disconnection/reconnection involved.
7. OS current practices
Most modern OSes (especially mobile ones) do implement by default
some MAC address randomization policy. Since the mechanism and
policies OSes implement can evolve with time, the content is now
hosted at https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-
address-randomization/blob/main/OS-current-practices.md. For
completeness, a snapshop of the content at the time of publication of
this document is included below.
Table 1 summarizes current practices for Androiod and iOS, as the
time of writing this document (original source:
https://www.fing.com/news/private-mac-address-on-ios-14, updated
based on findings from the authors).
Zuniga, et al. Expires 31 August 2024 [Page 11]
Internet-Draft Randomized and Changing MAC Address February 2024
+=============================================+===================+
| Android 10+ | iOS 14+ |
+=============================================+===================+
| The randomized MAC address is bound to the | The randomized |
| SSID | MAC address is |
| | bound to the |
| | BSSID |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+
| The randomized MAC address is stable across | The randomized |
| reconnections for the same network | MAC address is |
| | stable across |
| | reconnections for |
| | the same network |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+
| The randomized MAC address does not get re- | The randomized |
| randomized when the device forgets a WiFI | MAC address is |
| network | reset when the |
| | device forgets a |
| | WiFI network |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+
| MAC address randomization is enabled by | MAC address |
| default for all the new WiFi networks. But | randomization is |
| if the device previously connected to a | enabled by |
| WiFi network identifying itself with the | default for all |
| real MAC address, no randomized MAC address | the new WiFi |
| will be used (unless manually enabled) | networks |
+---------------------------------------------+-------------------+
Table 1: Android and iOS MAC address randomization practices
In September 2021, we have performed some additional tests to
evaluate how most widely used OSes behave regarding MAC address
randomization. Table 2 summarizes our findings, where show on
different rows whether the OS performs address randomization per
network, per new connection, daily, supports configuration per SSID,
supports address randomization for scanning, and whether it does that
by default.
Zuniga, et al. Expires 31 August 2024 [Page 12]
Internet-Draft Randomized and Changing MAC Address February 2024
+====================+=======+============+============+=========+
| OS | Linux | Android 10 | Windows 10 | iOS 14+ |
+====================+=======+============+============+=========+
| Random per net. | Y | Y | Y | Y |
+--------------------+-------+------------+------------+---------+
+--------------------+-------+------------+------------+---------+
| Random per connec. | Y | N | N | N |
+--------------------+-------+------------+------------+---------+
+--------------------+-------+------------+------------+---------+
| Random daily | N | N | Y | N |
+--------------------+-------+------------+------------+---------+
+--------------------+-------+------------+------------+---------+
| SSID config. | Y | N | N | N |
+--------------------+-------+------------+------------+---------+
+--------------------+-------+------------+------------+---------+
| Random. for scan | Y | Y | Y | Y |
+--------------------+-------+------------+------------+---------+
+--------------------+-------+------------+------------+---------+
| Random. for scan | N | Y | N | Y |
| by default | | | | |
+--------------------+-------+------------+------------+---------+
Table 2: Observed behavior from different OS (as of September
2022)
According to [privacy_android], starting in Android 12, Android uses
non-persistent randomization in the following situations: (i) a
network suggestion app specifies that non-persistant randomization be
used for the network (through an API); or (ii) the network is an open
network that hasn't encountered a captive portal and an internal
config option is set to do so (by default it is not).
8. IANA Considerations
N/A.
9. Security Considerations
Privacy considerations regarding tracking the location of a user
through the MAC address of this device are discussed throughout this
document. Given the informational nature of this document, no
protocols/solutions are specified, but current state of affairs is
documented.
Any future specification in this area would have to look into
security and privacy aspects, such as, but not limited to: i)
mitigating the problem of location privacy while minimizing the
impact on upper layers of the protocol stack; ii) providing means to
Zuniga, et al. Expires 31 August 2024 [Page 13]
Internet-Draft Randomized and Changing MAC Address February 2024
network operators to authenticate devices and authorize network
access despite the MAC addresses changing following some pattern;
and, iii) provide means for the device not to use MAC addresses it is
not authorized to use or that are currently in use.
A major conclusion of the work in IEEE Std 802E concerned the
difficulty of defending privacy against adversaries of any
sophistication. In particular it has been shown that individuals can
be successfully tracked by fingerprinting using aspects of their
communication other than MAC Addresses or other permanent
identifiers. Machine learning techniques facilitate fingerprinting
without the adversary needing to understand the technical reasons for
the correlation.
10. Acknowledgments
Authors would like to thank Guillermo Sanchez Illan for the extensive
tests performed on different OSes to analyze their behavior regarding
address randomization.
Authors would like to thank Jerome Henry, Hai Shalom, Stephen Farrel,
Alan DeKok, Mathieu Cunche, Johanna Ansohn McDougall, Peter Yee, Bob
Hinden, Behcet Sarikaya, David Farmer and Mohamed Boucadair for their
review and comments on previous versions of this document. Authors
would also like to thank Michael Richardson for his contributions on
the taxonomy section. Finally, authors would also like to thank the
IEEE 802.1 Working Group for its review and comments.
11. Informative References
[contact_tracing_paper]
Leith, D. J. and S. Farrell, "Contact Tracing App Privacy:
What Data Is Shared By Europe's GAEN Contact Tracing
Apps", IEEE INFOCOM 2021 , July 2020.
[enhancing_location_privacy]
Gruteser, M. and D. Grunwald, "Enhancing location privacy
in wireless LAN through disposable interface identifiers:
a quantitative analysis", Mobile Networks and
Applications, vol. 10, no. 3, pp. 315-325 , 2005.
[IEEE802.1AEdk-2023]
IEEE 802.1, "IEEE Std 802.1AEdk-2023: IEEE Standard for
Local and metropolitan area networks-Media Access Control
(MAC) Security - Amendment 4: MAC Privacy protection",
2023.
Zuniga, et al. Expires 31 August 2024 [Page 14]
Internet-Draft Randomized and Changing MAC Address February 2024
[IEEE_802] IEEE 802, "IEEE Std 802 - IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture",
IEEE 802 , 2014.
[IEEE_802c]
IEEE 802.1 WG - 802 LAN/MAN architecture, "IEEE 802c-2017
- IEEE Standard for Local and Metropolitan Area
Networks:Overview and Architecture--Amendment 2: Local
Medium Access Control (MAC) Address Usage", IEEE 802c ,
2017.
[IEEE_802E]
IEEE 802.1 WG - 802 LAN/MAN architecture, "IEEE 802E-2020
- IEEE Recommended Practice for Privacy Considerations for
IEEE 802 Technologies", IEEE 802E , 2020.
[IEEE_802_11_aq]
IEEE 802.11 WG - Wireless LAN Working Group, "IEEE
802.11aq-2018 - IEEE Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 5:
Preassociation Discovery", IEEE 802.11 , 2018.
[ieee_privacy_ecsg]
IEEE 802 Privacy EC SG, "IEEE 802 EC Privacy
Recommendation Study Group",
<http://www.ieee802.org/PrivRecsg/>.
[link_layer_privacy]
O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the
link layer", Contribution at W3C/IAB workshop on
Strengthening the Internet Against Pervasive Monitoring
(STRINT) , February 2014.
[privacy_android]
Android Open Source Project, "MAC Randomization Behavior",
<https://source.android.com/devices/tech/connect/wifi-mac-
randomization-behavior>.
[privacy_ios]
Apple, "Use private Wi-Fi addresses in iOS 14, iPadOS 14,
and watchOS 7",
<https://support.apple.com/en-us/HT211227>.
Zuniga, et al. Expires 31 August 2024 [Page 15]
Internet-Draft Randomized and Changing MAC Address February 2024
[privacy_tutorial]
Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P.
O'Hanlon, "Tutorial on Pervasive Surveillance of the
Internet - Designing Privacy into Internet Protocols",
<https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-
internet-privacy-tutorial.pdf>.
[privacy_windows]
Microsoft, "Windows: How to use random hardware
addresses", <https://support.microsoft.com/en-us/windows/
how-to-use-random-hardware-addresses-ac58de34-35fc-31ff-
c650-823fc48eb1bc>.
[rcm_privacy_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1346r1 , 2020.
[rcm_privacy_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on privacy
mechanisms", doc.:IEEE 802.11-19/854r7 , 2020.
[rcm_tig_final_report]
IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And
Changing MAC Addresses Topic Interest Group Report",
doc.:IEEE 802.11-19/1442r9 , 2019.
[rcm_user_experience_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1117r3 , 2020.
[rcm_user_experience_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on user experience
mechanisms", doc.:IEEE 802.11-20/742r5 , 2020.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
Zuniga, et al. Expires 31 August 2024 [Page 16]
Internet-Draft Randomized and Changing MAC Address February 2024
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer
Address Assignment Mechanism for DHCPv6", RFC 8947,
DOI 10.17487/RFC8947, December 2020,
<https://www.rfc-editor.org/info/rfc8947>.
[RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address
Plan (SLAP) Quadrant Selection Option for DHCPv6",
RFC 8948, DOI 10.17487/RFC8948, December 2020,
<https://www.rfc-editor.org/info/rfc8948>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[strint] W3C/IAB, "A W3C/IAB workshop on Strengthening the Internet
Against Pervasive Monitoring (STRINT)",
<https://www.w3.org/2014/strint/>.
[wba_paper]
Alliance, W. B., "Wi-Fi Identification Scope for Liasing -
In a post MAC Randomization Era", doc.:WBA Wi-Fi ID Intro:
Post MAC Randomization Era v1.0 - IETF liaison , March
2020.
Zuniga, et al. Expires 31 August 2024 [Page 17]
Internet-Draft Randomized and Changing MAC Address February 2024
[when_mac_randomization_fails]
Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown,
L., Riggins, C., Rye, E.C., and D. Brown, "A Study of MAC
Address Randomization in Mobile Devices and When it
Fails", arXiv:1703.02874v2 [cs.CR] , 2017.
[wifi_internet_privacy]
Bernardos, CJ., Zúñiga, JC., and P. O'Hanlon, "Wi-Fi
Internet Connectivity and Privacy: Hiding your tracks on
the wireless Internet", Standards for Communications and
Networking (CSCN), 2015 IEEE Conference on , October 2015.
[wifi_tracking]
The Independent, "London's bins are tracking your
smartphone", <https://www.independent.co.uk/life-style/
gadgets-and-tech/news/updated-london-s-bins-are-tracking-
your-smartphone-8754924.html>.
Authors' Addresses
Juan Carlos Zuniga
CISCO
Montreal QC
Canada
Email: juzuniga@cisco.com
Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Amelia Andersdotter
Safespring AB
Email: amelia.ietf@andersdotter.cc
Zuniga, et al. Expires 31 August 2024 [Page 18]