MADINAS
Internet Engineering Task Force (IETF) JC. Zúñiga
Internet-Draft CISCO
Intended status:
Request for Comments: 9724 Cisco
Category: Informational CJ. Bernardos, Ed.
Expires: 16 January 2025
ISSN: 2070-1721 UC3M
A. Andersdotter
Safespring AB
15 July 2024
January 2025
Randomized and Changing MAC Media Access Control (MAC) Address State of
Affairs
draft-ietf-madinas-mac-address-randomization-15
Abstract
Internet 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 of
Internet users is the wide use of long-lasting, and sometimes
persistent, identifiers at various protocol layers. This document
focuses on MAC Media Access Control (MAC) addresses.
There have been several initiatives within the IETF and the IEEE 802
standards committees to overcome some of these the privacy issues. issues involved.
This document provides an overview of these activities to help
coordinating
coordinate standardization activities in these bodies.
Status of This Memo
This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents valid
approved by the IESG are candidates for a maximum any level of six months Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 16 January 2025.
https://www.rfc-editor.org/info/rfc9724.
Copyright Notice
Copyright (c) 2024 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(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 Address Usage
2.2. MAC address randomization . . . . . . . . . . . . . . . . 4 Address Randomization
2.3. Privacy Workshop, Tutorial Tutorial, and Experiments at IETF and
IEEE 802 meetings . . . . . . . . . . . . . . . . . . . . . . 5 Meetings
3. Activities Relating to Randomized and Changing MAC addresses activities at Addresses in
the IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Recent Activities Related to MAC randomization-related activities at Randomization in the WBA . . . 7
5. IPv6 address randomization at Address Randomization in the IETF . . . . . . . . . . . 8
6. A taxonomy Taxonomy of MAC address selection policies . . . . . . . . 9 Address Selection Policies
6.1. Per-Vendor OUI MAC address Address (PVOM) . . . . . . . . . . . . 10
6.2. Per-Device Generated MAC address Address (PDGM) . . . . . . . . . 10
6.3. Per-Boot Generated MAC address Address (PBGM) . . . . . . . . . . 10
6.4. Per-Network Generated MAC address Address (PNGM) . . . . . . . . 10
6.5. Per-Period Generated MAC address Address (PPGM) . . . . . . . . . 11
6.6. Per-Session Generated MAC address Address (PSGM) . . . . . . . . 11
7. OS current practices . . . . . . . . . . . . . . . . . . . . 11 Current Practices
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . 14
Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Privacy is becoming a huge concern, as more and more devices are
getting
connecting to the Internet either directly (e.g., via Wi-Fi) or
indirectly (e.g., via a smartphone using Bluetooth) connected to the Internet. Bluetooth). This ubiquitous
connectivity, together with the lack of proper education about privacy make
privacy, makes it very easy to track/monitor the location of users
and/or eavesdrop on 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 consent and the weak (or
even null) authentication and encryption mechanisms used to secure
communications. A digital footprint may include information shared
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) Layer 2
(L2) address (i.e., MAC address) or Layer-3 Layer 3 (L3) address, web
trackers,
etc.; and/or the weak (or even null in some cases) authentication and
encryption mechanisms used to secure communications.
This privacy concern affects etc.
Privacy concerns affect all layers of the protocol stack, from the
lower layers involved in the access to the network (e.g., the
MAC/Layer-2 MAC/L2 and Layer-3
L3 addresses can be used to obtain the location of a user) to higher higher-
layer protocol identifiers and user applications [CSCN2015]. In
particular, IEEE 802 MAC addresses have historically been an easy
target for tracking users [wifi_tracking].
There have been several initiatives at 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 coordinate
standardization activities within these bodies.
2. Background
2.1. MAC address usage 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
Like any other kind of IEEE 802-based network
interface, like interface based on IEEE 802 such as
Ethernet (i.e., IEEE 802.3) 802.3), Wi-Fi interfaces have a Layer-2 an L2 address
also
(also referred to as a MAC address, which address) that can be seen by anybody who
can receive the radio signal transmitted by the network interface.
The format of these addresses (for 48-bit MAC 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 (for 48-bit addresses) 48-Bit Addresses)
MAC addresses can either be either universally administered or locally administered.
Universally administered and locally administered addresses are distinguished by
setting the second-least-significant second least significant bit of the most significant byte
of the address (the U/L bit).
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 (OUI): The first three octets in
transmission order and order, which identify the organization that issued
the identifier, and (ii) identifier.
Network Interface Controller (NIC)
Specific, which are the Specific: The following three
octets, which are 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 set up by either the network administrator, administrator or by the
Operating System (OS) of the device to which the address pertains.
However, as explained in further later sections of this document, there are
new initiatives at in 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 Address Randomization
Since universally administered MAC addresses are by definition
globally unique, when a device uses this MAC address over a shared
medium to transmit data -especially -- especially over the air- 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 layer-2 L2 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 (a.k.a. (also known as
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 unicast address fields of an IEEE 802.11 frame.
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 to be generated without the need of for 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)
OSes reporting persistently (every 20 minutes or so) on MAC addresses (among
(as well as other information), which would defeat MAC address
randomization. While these practices might have changed by now, it
is important to highlight that privacy preserving privacy-preserving techniques should
be conducted while considering all layers of the protocol stack.
2.3. Privacy Workshop, Tutorial Tutorial, and Experiments at IETF and IEEE 802
meetings
Meetings
As an outcome to the STRINT W3C/IAB Workshop [strint], a tutorial on
titled "Pervasive Surveillance of the Internet - Designing Privacy
into Internet Protocols" [privacy_tutorial] 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 Standards Development Organizations
(SDOs) like the IETF, and guidelines that were being followed when
developing new Internet protocol specifications (e.g., the
considerations described in [RFC6973]). The tutorial highlighted
some privacy concerns applicable that apply specifically to link-layer
technologies and provided suggestions on how IEEE 802 could help addressing
address them.
Following the discussions and interest within the IEEE 802 community,
on 18 July 2014 2014, the IEEE 802 Executive Committee (EC) created an the
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 (Project Authorization
Request, this is the means by which standards projects are started
within the IEEE. PARs define the scope, purpose, and contact points
for a new project): 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 -
Amendment 2: 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 -- IETF 91, IETF 92, and the IEEE 802 Plenary in
Berlin. The purpose of the trials was to evaluate the use of MAC
address randomization from two different perspectives: (i) (1) the effect
on the connectivity experience of the end-user, also checking if end user, as well as any effect
on applications and OSes were affected; OSes, and (ii) (2) the potential impact on the network
infrastructure itself. Some of the findings were published in
[CSCN2015].
During the trials 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., the DHCP client identifier)
can be correlated and can therefore still be used to still track an
individual. Hence, effective privacy tools should not work in
isolation at a single layer, but layer; instead; they should be coordinated with
other privacy features at higher layers.
Since then, MAC randomization has further been further implemented by mobile
OSes to provide better privacy for mobile phone users when connecting
to public wireless networks [privacy_ios], [privacy_windows], [privacy_ios] [privacy_windows]
[privacy_android].
3. Activities Relating to Randomized and Changing MAC addresses activities at Addresses in the
IEEE 802
Practical experiences of with Randomized and Changing MAC addresses
(RCM) in devices (some of them which are explained in Section Section 6) helped
researchers fine-tune their understanding of attacks against
randomization mechanisms [when_mac_randomization_fails]. At Within the
IEEE 802.11 group group, these research experiences eventually formed the
basis for a specified mechanism that randomizes MAC addresses, which
was introduced in the IEEE Std 802.11aq [IEEE_802.11aq] in 2018
which randomize MAC addresses [IEEE_802_11_aq]. 2018.
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 a
potentially large uptake of randomized MAC identifiers on a number of
commonly offered operator services in 2019[rcm_tig_final_report]. 2019 [rcm_tig_final_report].
In the summer of 2020 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 (a group of
interconnected IEEE 802.11 wireless access points and stations that
form a single logical network) 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) [RFC8948]. The SLAP
designates a range of Extended Local Identifiers for subassignment
within a block of addresses assigned by the IEEE Registration
Authority via a Company ID. A range of local MAC addresses is
designated for Standard Assigned Identifiers to be specified by IEEE
802 standards. Another range of local MAC addresses is designated
for Administratively Assigned Identifiers Identifiers, which are subject to
assignment by a network administrator.
"IEEE
IEEE Std 802E-2020: 802E-2020 ("IEEE Recommended Practice for Privacy
Considerations for IEEE 802 Technologies" 802(R) 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 (a.k.a. Wi-Fi) devices (also known as Wi-Fi
devices) as part of the RCM [rcm_privacy_csd] efforts. efforts [rcm_privacy_csd]. Annex T of
IEEE Std 802.1AEdk-2023:
MAC 802.1AEdk-2023 ("MAC Privacy Protection [IEEE802.1AEdk-2023] Protection") [IEEE_802.1AEdk]
discusses privacy considerations in bridged networks.
As per of 2024, two task groups in IEEE 802.11 are dealing with issues
related to RCM:
* The IEEE 802.11bh task group, which is looking at mitigating the
repercussions that RCM creates on 802.11 networks and related
services, and
services.
* The IEEE 802.11bi task group, which is chartered to define
modifications to the IEEE Std 802.11 medium access control (MAC) MAC specification to specify
new mechanisms that address and improve user privacy.
4. Recent Activities Related to MAC randomization-related activities at Randomization in the WBA
At
In 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, the WBA has documented a set of use cases that
a Wi-Fi Identification Standard should address in order to scale and
achieve longer term 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].
5. IPv6 address randomization at Address Randomization in the IETF
[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,
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
IID based on the MAC address-based IID, address, 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 SLAAC that
causes hosts to generate temporary addresses with randomized
interface identifiers IIDs 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, 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 IIDs 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, 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 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 which
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.
[RFC7217] describes a method to generate Interface Identifiers IIDs that are stable for
each network interface within each subnet, subnet but that change as a host moves
from one network to another. This method enables keeping the "stability"
properties of the Interface
Identifiers IIDs specified in [RFC4291], [RFC4291] to be kept, while still
mitigating address-
scanning 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 that takes the following as input input: information that is
stable and associated to the interface (e.g., a local interface identifier), IID), stable
information associated to the visited network (e.g., IEEE 802.11
SSID), the IPv6 prefix, and a secret key, plus and some other additional
information. This basically ensures that a different IID is
generated when any one of the input fields changes (such as the network
or the prefix), prefix) but that the IID is the same within each subnet.
Currently,
To mitigate the privacy threats posed by the use of MAC-derived IIDs,
[RFC8064] recommends that 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. SLAAC.
In addition to the former documents, documents above, [RFC8947] proposes "an extension
to a DHCPv6 that
extension 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". are unnecessary.
And [RFC8948] proposes "extensions to DHCPv6 protocols to extensions that:
| enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred
| SLAP quadrant to the server, server so that the server may allocate MAC
| addresses in the quadrant requested by the relay or client".
Not only client.
In addition to MAC and IP addresses addresses, some DHCP options that carry
unique identifiers can also 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 profiles that are:
| designed for clients that wish to remain anonymous to the visited
network. The profiles
| network
and that:
| provide guidelines on the composition of DHCP or DHCPv6 messages,
| designed to minimize disclosure of identifying
information". information.
[RFC7844] also indicates that the link-layer address, IP address, and
DHCP identifier shall evolve in synchrony.
6. A taxonomy Taxonomy of MAC address selection policies Address Selection Policies
This section documents different policies for MAC address selection.
Some OSes might use a combination of multiple of these policies.
Note about the used naming convention: the convention used: The "M" in MAC "MAC" is included
in the acronym, acronym but not the "A" from address. "Address". This allows one to
talk about a PVOM Address, Address or PNGM Address.
6.1. Per-Vendor OUI MAC address Address (PVOM)
This form of MAC address selection is the historical default.
The vendor obtains an Organizationally Unique Identifier (OUI) OUI from the IEEE. This has been is a 24-bit prefix
(including two upper bits
which that are set specifically) that is assigned
to the vendor. The vendor generates a unique 24-bit value for the
lower 24-bits, 24 bits, forming the 48-bit MAC address. It has is 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 uses 64-bit MAC addresses, and the IEEE assigns
32-bit prefixes. The IEEE has indicated that there may be a future
Ethernet specification using that uses 64-bit MAC addresses.
6.2. Per-Device Generated MAC address 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 Address (PBGM)
This form of MAC address is randomly generated by the device, 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 Address (PNGM)
This form of MAC address is generated each time a new network
attachment is created.
This is typically used with Wi-Fi (802.11) networks where the network
is identified by an SSID Name. The generated address is stored on in
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 traffic (such as STP
[IEEE802.1D-2004], LLDP [IEEE802.1AB-2016], DHCP
[IEEE_802.1D], the Link Layer Discovery Protocol (LLDP)
[IEEE_802.1AB], DHCP, or Router
Advertisements Advertisements) to determine which
network has been attached.
6.5. Per-Period Generated MAC address Address (PPGM)
This form of MAC address is generated periodically. Typical numbers
are periodically, typically around
every twelve hours. Like PNGM, it is used primarily with Wi-Fi.
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, Extensible Authentication
Protocol (EAP), TLS, etc. negotiations. A new DHCP, SLAAC will be
done.
If DHCP is used, then a new DUID DHCP Unique Identifier (DUID) is
generated so as to not link to the previous connection, and the result is connection; this usually
results in the allocation of new IP addresses
allocated. addresses.
6.6. Per-Session Generated MAC address Address (PSGM)
This form of MAC address is generated on a per session per-session basis. How a
session is defined is implementation-dependant, implementation-dependent, for example, a
session might be defined by logging in to a portal, VPN, etc. Like
PNGM, it PSGM is used primarily with Wi-Fi.
Since the address changes only changes when a new session is established,
there is no disconnection/reconnection involved.
7. OS current practices
Most Current Practices
By default, most modern OSes (especially mobile ones) do implement by default
some MAC address randomization policy. policies. Since the mechanism and
policies that 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. [OS_current_practices]. For completeness, a snapshot of
the content at the time of publication of this document is included
below. Note that the extensive testing reported in this document was
conducted in 2021, but no significant changes have been detected at
the time of publication of this document.
Table 1 summarizes current practices for Android and iOS, as iOS at the time
of writing this document (original (the original source posted at:
https://www.fing.com/news/private-mac-address-on-ios-14, latest
wayback machine's snapshot is available here:
https://web.archive.org/web/20230905111429/https://www.fing.com/news/
private-mac-address-on-ios-14, updated at
[private_mac]) and also includes updates based on findings from the
authors).
authors.
+=============================================+===================+
| Android 10+ | iOS 14+ |
+=============================================+===================+
| The randomized MAC address is bound to the | The randomized |
| SSID SSID. | MAC address is |
| | bound to the |
| | Basic SSID SSID. |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+
| The randomized MAC address is stable across | The randomized |
| reconnections for the same network network. | MAC address is |
| | stable across |
| | reconnections for |
| | the same network network. |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+
| The randomized MAC address does not get re- | The randomized |
| randomized when the device forgets a WiFI Wi-Fi | MAC address is |
| network network. | reset when the |
| | device forgets a |
| | WiFI network Wi-Fi network. |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+
| MAC address randomization is enabled by | MAC address |
| default for all the new Wi-Fi networks. | randomization is |
| But if the device previously connected to a | enabled by |
| Wi-Fi network identifying itself with the | default for all |
| real MAC address, no randomized MAC address | the new Wi-Fi |
| will be used (unless manually enabled) enabled). | networks networks. |
+---------------------------------------------+-------------------+
Table 1: Android and iOS MAC address randomization practices Address Randomization Practices
In September 2021, we have performed some additional tests to evaluate how most
OSes that are widely used OSes behave regarding MAC address randomization.
Table 2 summarizes our findings, where show on
different findings; the rows in the table show whether
the OS performs address randomization per network (PNGM according to
the taxonomy introduced in Section 6), performs address randomization
per new connection (PSGM), performs address randomization daily (PPGM
with a period of 24h), 24 hours), supports configuration per SSID, supports
address randomization for scanning, and whether it does that supports address
randomization for scanning by default.
+=================+===============+=========+=========+=====+
| OS | Linux (Debian | Android | Windows | iOS |
| | "bookworm") | 10 | 10 | 14+ |
+=================+===============+=========+=========+=====+
| Random per net. | Y | Y | Y | Y |
| (PNGM) | | | | |
+-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| Random per | Y | N | N | N |
| connec. (PSGM) | | | | |
+-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| Random daily | N | N | Y | N |
| (PPGM) | | | | |
+-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| SSID config. | Y | N | N | N |
+-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| Random. for | Y | Y | Y | Y |
| scan | | | | |
+-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| Random. for | N | Y | N | Y |
| scan by default | | | | |
+-----------------+---------------+---------+---------+-----+
Table 2: Observed behavior from different OS Behavior in Different OSes (as of
September 2021)
According to [privacy_android], starting in with Android 12, Android
uses non-persistent randomization in the following situations: (i) a
* A network suggestion app application specifies that non-persistant non-persistent
randomization be used for the network (through an API); or (ii) the API).
* The network is an open network that hasn't encountered a captive portal
portal, and an internal config option is set to do so (by default default,
it is not).
8. IANA Considerations
This document has no IANA actions.
9. Security Considerations
Privacy considerations regarding tracking the location of a user
through the MAC address of this a device are discussed throughout this
document. Given the informational nature of this document, no
protocols/solutions are specified, but the current state of affairs
is documented.
Any future specification in this area would have need to look into
security and privacy aspects, such as, but as (but not limited to: i)
mitigating to) the
following:
* Mitigating the problem of location privacy while minimizing the
impact on upper layers of the protocol stack; ii) providing stack
* Providing the means to for network operators to authenticate devices
and authorize network
access access, despite the MAC addresses changing following
according some pattern;
and, iii) provide pattern
* Providing the means for the device not to use MAC addresses that
it is not authorized to use or that are currently in use. use
A major conclusion of the work in IEEE Std 802E concerned the
difficulty of defending privacy against adversaries of any
sophistication. Individuals can be successfully tracked by
fingerprinting
fingerprinting, using aspects of their communication other than MAC
Addresses
addresses or other permanent identifiers.
11.
10. 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. - IEEE Conference on Computer
Communications, DOI 10.1109/INFOCOM42981.2021.9488728, May
2021, <https://ieeexplore.ieee.org/document/9488728>.
[CSCN2015] Bernardos, CJ., Zúñiga, JC., and P. O'Hanlon, "Wi-Fi
Internet Connectivity and Privacy: Hiding your tracks on
the wireless Internet", 2015 IEEE Conference on Standards
for Communications and Networking (CSCN), 2015 IEEE Conference on ,
DOI 10.1109/CSCN.2015.7390443, October 2015. 2015,
<https://doi.org/10.1109/CSCN.2015.7390443>.
[enhancing_location_privacy]
Gruteser, M. and D. Grunwald, "Enhancing location privacy Location Privacy
in wireless Wireless LAN through disposable interface identifiers:
a quantitative analysis", Through Disposable Interface Identifiers:
A Quantitative Analysis", Mobile Networks and
Applications, vol. 10, no. 3, pp. 315-325 , 2005.
[IEEE802.1AB-2016]
IEEE 802.1, 315-325,
DOI 10.1007/s11036-005-6425-1, June 2005,
<https://doi.org/10.1007/s11036-005-6425-1>.
[IEEE_802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802.1AB-2016: 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, June 2014,
<https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEE_802.11aq]
IEEE, "IEEE Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area network--Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 5:
Preassociation Discovery", IEEE Std 802.11aq-2018,
DOI 10.1109/IEEESTD.2018.8457463, August 2018,
<https://doi.org/10.1109/IEEESTD.2018.8457463>.
[IEEE_802.1AB]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Station and Media Access Control Connectivity
Discovery", 2016.
[IEEE802.1AEdk-2023] IEEE 802.1, "IEEE Std 802.1AEdk-2023: IEEE 802.1AB-2016,
DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>.
[IEEE_802.1AEdk]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security - Amendment
4: MAC Privacy protection",
2023.
[IEEE802.1D-2004] IEEE 802.1, "IEEE Std 802.1D-2004: IEEE 802.1AEdk-2023,
DOI 10.1109/IEEESTD.2023.10225636, August 2023,
<https://doi.org/10.1109/IEEESTD.2023.10225636>.
[IEEE_802.1D]
IEEE, "IEEE Standard for Local and metropolitan area
networks: Media Access Control (MAC) Bridges", 2004.
[IEEE_802] IEEE 802, "IEEE Std 802 - IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture",
IEEE 802 , 2014.
802.1D-2004, DOI 10.1109/IEEESTD.2004.94569, June 2004,
<https://ieeexplore.ieee.org/document/1309630>.
[IEEE_802c]
IEEE 802.1 WG - 802 LAN/MAN architecture,
IEEE, "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. Std 802c-
2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017,
<https://doi.org/10.1109/IEEESTD.2017.8016709>.
[IEEE_802E]
IEEE 802.1 WG - 802 LAN/MAN architecture,
IEEE, "IEEE 802E-2020
- IEEE Recommended Practice for Privacy
Considerations for IEEE 802 802(R) 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. Std
802E-2020, DOI 10.1109/IEEESTD.2020.9257130, November
2020, <https://doi.org/10.1109/IEEESTD.2020.9257130>.
[ieee_privacy_ecsg]
IEEE 802 Privacy EC SG, LAN/MAN Standards Committee, "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) , (STRINT), February
2014.
[OS_current_practices]
"OS current practices", commit 795739b, July 2024,
<https://github.com/ietf-wg-madinas/draft-ietf-madinas-
mac-address-randomization/blob/main/OS-current-
practices.md>.
[privacy_android]
Android Open Source Project, "MAC Randomization Behavior", randomization behavior",
Android OS Documentation,
<https://source.android.com/devices/tech/connect/wifi-mac-
randomization-behavior>.
[privacy_ios]
Apple,
Apple Inc., "Use private Wi-Fi addresses in iOS 14, iPadOS 14,
and watchOS 7",
<https://support.apple.com/en-us/HT211227>. on Apple
Devices", Apple Support,
<https://support.apple.com/en-us/102509>.
[privacy_tutorial]
Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P.
O'Hanlon, "Tutorial on Pervasive "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>. IEEE 802
Tutorial, 14 July 2014, <https://mentor.ieee.org/802-
ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-
tutorial.pdf>.
[privacy_windows]
Microsoft, "Windows: How
Microsoft Corporation, "How to use random hardware
addresses", <https://support.microsoft.com/en-us/windows/
how-to-use-random-hardware-addresses-ac58de34-35fc-31ff-
addresses in Windows", Microsoft Support,
<https://support.microsoft.com/en-us/windows/how-to-use-
random-hardware-addresses-ac58de34-35fc-31ff-
c650-823fc48eb1bc>.
[private_mac]
Pantaleone, D., "Private MAC address on iOS 14", Wayback
Machine archive, September 2020,
<https://web.archive.org/web/20230905111429/
https://www.fing.com/news/private-mac-address-on-ios-14>.
[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 , 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 , 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 , 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 , 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 , 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>.
[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. CJ. 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 "STRINT Workshop: A W3C/IAB workshop on
Strengthening the Internet Against Pervasive Monitoring
(STRINT)", <https://www.w3.org/2014/strint/>.
[wba_paper]
Wireless Broadband 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 ,
liaison, March 2020.
[when_mac_randomization_fails]
Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown,
L., Riggins, C., Rye, E.C., E., and D. Brown, "A Study of MAC
Address Randomization in Mobile Devices and When it
Fails", arXiv:1703.02874v2 [cs.CR] , 2017. arXiv:1703.02874v2, DOI 10.48550/arXiv.1703.02874,
March 2017, <https://doi.org/10.48550/arXiv.1703.02874>.
[wifi_tracking]
The Independent,
Vincent, J., "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>.
10.
The Independent, 9 August 2013,
<https://www.independent.co.uk/life-style/gadgets-and-
tech/news/updated-london-s-bins-are-tracking-your-
smartphone-8754924.html>.
Acknowledgments
Authors
The authors would like to thank Guillermo Sanchez Illan for the
extensive tests performed on different OSes to analyze their behavior
regarding address randomization.
Authors
The authors would also like to thank Jerome Henry, Hai Shalom,
Stephen Farrel, Farrell, Alan DeKok, Mathieu Cunche, Johanna Ansohn
McDougall, Peter Yee, Bob Hinden, Behcet Sarikaya, David Farmer,
Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roma Roman Danyliw,
Murray Kucherawy Kucherawy, and Paul Wouters for their reviews and comments on
previous draft versions of this document. Authors In addition, the authors
would also like to thank Michael Richardson for his contributions on the
taxonomy section. Finally, the authors would
also like to thank the IEEE
802.1 Working Group for its review and comments, performed as part of
the Liaison "Liaison statement on Randomized and Changing MAC Address (https://datatracker.ietf.org/
liaison/1884/). Address"
(https://datatracker.ietf.org/liaison/1884/).
Authors' Addresses
Juan Carlos Zúñiga
CISCO
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