Randomized and Changing MAC Address state of affairs

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.¶

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

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, 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

        +--------+--------+---------+--------+--------+---------+
        |  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
+--+--+--+--+--+--+--+--+

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 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].¶

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.¶

[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.¶

The names are all in the form for per-period-of-time-selection.¶

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).¶

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.¶

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 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.¶

Authors' Addresses