Internet Engineering Task Force J. Henry Internet-Draft Cisco Systems Intended status: Informational Y. Lee Expires: 25 December 2024 Comcast 23 June 2024 Randomized and Changing MAC Address Use Cases draft-ietf-madinas-use-cases-10 Abstract To limit the privacy issues created by the association between a device, its traffic, its location and its user, client and client OS vendors have started implementing MAC address rotation. When such a rotation happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the MAC rotation purposes. This document lists various network environments and a set of network services that may be affected by such rotation. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines solutions to maintain user privacy while preserving user quality of experience and network operation efficiency. 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 25 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Henry & Lee Expires 25 December 2024 [Page 1] Internet-Draft RCM Use Cases June 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. MAC Address as Identity: User vs. Device . . . . . . . . . . 3 3. The Actors: Network Functional Entities and Human Entities . 6 3.1. Network Functional Entities . . . . . . . . . . . . . . . 6 3.2. Human-related Entities . . . . . . . . . . . . . . . . . 7 4. Trust Degrees . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Environments . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Network Services . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Device Identification and Associated Problems . . . . . . 11 6.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . 15 Appendix A. Existing solutions . . . . . . . . . . . . . . . . . 16 A.1. 802.1X with WPA2 / WPA3 . . . . . . . . . . . . . . . . . 16 A.2. OpenRoaming . . . . . . . . . . . . . . . . . . . . . . . 17 A.3. Proprietary RCM schemes . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction IEEE 802.11 (or 'Wi-Fi') [IEEE_802.11] technology has revolutionized communications and become the preferred, and sometimes the only technology used by devices such as laptops, tablets and Internet-of- Thing (IoT) devices. Wi-Fi is an over-the-air technology, attackers with surveillance equipment can "monitor" WLAN packets and track the activity of WLAN devices. Once the association between a device and its user is made, identifying the device and its activity is sufficient to deduce information about what the user is doing, without the user consent. To reduce the risks of correlation between a device activity and its owner's, multiple client and client OS vendors have started to implement Randomized and Changing MAC addresses (RCM). By randomizing the MAC address, the persistent association between a given traffic flow and a single device is made more difficult, assuming no other visible unique identifiers or stable patterns are Henry & Lee Expires 25 December 2024 [Page 2] Internet-Draft RCM Use Cases June 2024 in use. When individual devices are no longer easily identifiable, it also becomes difficult to associate a series of network flows with a particular individual using one particular device. However, such address change may affect the user experience and the efficiency of legitimate network operations. For a long time, network designers and implementers relied on the assumption that a given machine, in a network implementing [IEEE_802] technologies, would be represented by a unique network MAC address that would not change over time, despite the existence of tools to flush out the MAC address to bypass some network policies. When this assumption is broken, network communication may be disrupted. For example, sessions established between the end-device and network services may break and packets in transit may suddenly be lost. If multiple clients implement fast-paced RCM rotations without coordination with network services, these network services may become over-solicited. At the same time, some network services rely on the end station (as defined by the [IEEE_802] Standard) providing an identifier, which can be the MAC address or another value. If the client implements MAC rotation but continues sending the same static identifier, then the association between a stable identifier and the station continues despite the RCM scheme. There may be environments where such continued association is desirable, but others where the user privacy has more value than any continuity of network service state. There is a need to enumerate services that may be affected by RCM, and evaluate possible solutions to maintain both the quality of user experience and network efficiency while RCM happens and user privacy is reinforced. This document presents such assessment and recommendations. 2. MAC Address as Identity: User vs. Device Any device member of a network implementing IEEE 802 technologies includes several operating layers. Among them, the Media Access Control (MAC) layer defines rules to control how the device accesses the shared medium. In a network where a machine can communicate with one or more other machines, one such rule is that each machine needs to be identified, either as the target destination of a message, or as the source of a message (and thus the target destination of the answer). Initially intended as a 48-bit (6 octets) value in the first versions of the [IEEE_802] Standard, other Standards under the [IEEE_802] umbrella then allowed this address to take an extended format of 64 bits (8 octets), thus enabling a larger number of MAC addresses to coexist as the 802 technologies became widely adopted. Henry & Lee Expires 25 December 2024 [Page 3] Internet-Draft RCM Use Cases June 2024 Regardless of the address length, different networks have different needs, and several bits of the first octet are reserved for specific purposes. In particular, the first bit is used to identify the destination address either as an individual (bit set to 0) or a group address (bit set to 1). The second bit, called the Universally or Locally Administered (U/L) Address Bit, indicates whether the address has been assigned by a local or universal administrator. Universally administered addresses have this bit set to 0. If this bit is set to 1, the entire address (i.e., 48 bits) has been locally administered (clause 8.4 of [IEEE_802]). The intent of this provision is important for the present document. The [IEEE_802] Standard recognized that some devices may never change their attachment network and thus would not need a globally unique MAC address to prevent address collision against any other device in any other network. To accommodate for this requirement, the second bit of the MAC address first octet was designed to express whether the address was intended to be globally unique, or locally unique. The address allocation method was not defined in the Standard in this later case, but the same clause defined that an address should be unique so as to avoid collision with any other device attached to the same network. It is also important to note that the purpose of the Universal version of the address was to avoid collisions and confusion, as any machine could connect to any network, and each machine needs to determine if it is the intended destination of a message or its response. Clause 8.4 of [IEEE_802] reminds network designers and operators that all potential members of a network need to have a unique identifier in that network (if they are going to coexist in the network without confusion on which machine is the source or destination or any message). The advantage of a universal address is that a node with such an address can be attached to any Local Area Network (LAN) in the world with an assurance that its address is unique in that network. With the rapid development of wireless technologies and mobile devices, this scenario became very common. With a vast majority of networks implementing [IEEE_802] radio technologies at the access, the MAC address of a wireless device can appear anywhere on the planet and collisions should still be avoided. However, the same evolution brought the distinction between two types of devices that the [IEEE_802] Standard generally referred to as ‘nodes in a network’. Their definition is found in the [IEEE_802E] Recommended Practice stated in Section 6.2 of [IEEE_802]. One type is a shared service device, which functions are used by a number of people large enough that the device itself, its functions or its traffic cannot be associated with a single or small group of people. Examples of such Henry & Lee Expires 25 December 2024 [Page 4] Internet-Draft RCM Use Cases June 2024 devices include switches in a dense network, IEEE 802.11 (WLAN) access points in a crowded airport, task-specific (e.g., barcode scanners) devices, etc. Another type is a personal device, which is a machine, a node, primarily used by a single person or small group of people, and so that any identification of the device or its traffic can also be associated to the identification of the primary user or their traffic. Quite naturally, the identification of the device is trivial if the device expresses a universally unique MAC address. Then, the detection of elements directly or indirectly identifying the user of the device (Personally Identifiable Information, or PII) is sufficient to tie the universal MAC address to a user. Then, any detection of traffic that can be associated to the device becomes also associated with the known user of that device (Personally Correlated Information, or PCI). This possible identification or association presents a serious privacy issue, especially with wireless technologies. For most of them, and in particular for 802.11, the source and destination MAC addresses are not encrypted even in networks that implement encryption (so that each machine can easily detect if it is the intended target of the message before attempting to decrypt its content, and also identify the transmitter, so as to use the right decryption key when multiple unicast keys are in effect). This identification of the user associated to a node was clearly not the intent of the 802 MAC address. A logical solution to remove this association is to use a locally administered address instead, and change the address in a fashion that prevents a continuous association between one MAC address and some PII. However, other network devices on the same LAN implementing a MAC layer also expect each device to be associated to a MAC address that would persist over time. When a device changes its MAC address, other devices on the same LAN may fail to recognize that the same machine is attempting to communicate with them. Additionally, multiple layers implemented at upper OSI layers have been designed with the assumption that each node on the LAN, using these services, would have a MAC address that would stay the same over time, and that this document calls a 'persistent' MAC address. This assumption sometimes adds to the PII confusion, for example in the case of Authentication, Association and Accounting (AAA) services authenticating the user of a machine and associating the authenticated user to the device MAC address. Other services solely focus on the machine (e.g., DHCP), but still expect each device to use a persistent MAC address, for example to re-assign the same IP address to a returning device. Changing the MAC address may disrupt these services. Henry & Lee Expires 25 December 2024 [Page 5] Internet-Draft RCM Use Cases June 2024 3. The Actors: Network Functional Entities and Human Entities The risk of service disruption is thus weighted against the privacy benefits. However, the plurality of actors involved in the exchanges tends to blur the boundaries of what privacy should be protected against. It might therefore be useful to list the actors associated to the network exchanges, either because they actively participate to these exchanges, or because they can observe them. Some actors are functional entities, some others are humans (or related) entities. 3.1. Network Functional Entities Network communications based on IEEE 802 technologies commonly rely on station identifiers based on a MAC address. This MAC address is utilized by several types of network functional entitities (entities, like applications or devices, that provide a service related to network operations). Wireless access network infrastructure devices (e.g., WLAN access points or controllers): these devices participate in IEEE 802 LAN operations. As such, they need to identify each machine as a source or destination so as to successfully continue exchanging frames. Part of the identification includes recording, and adapting to, devices communication capabilities (e.g., support for specific protocols). As a device changes its network attachment (roams) from one access point to another, the access points can exchange contextual information (e.g., device MAC, keying material) allowing the device session to continue seamlessly. These access points can also inform devices further in the wired network about the roam, to ensure that OSI model Layer 2 frames are redirected to the new device access point. Other network devices operating at the MAC layer: many wireless network access devices (e.g., IEEE 802.11 access points) are conceived as Layer 2 devices, and as such they bridge a frame from one medium (e.g., IEEE 802.11 or Wi-Fi) to another (e.g., IEEE 802.3 or Ethernet). This means that a wireless device MAC address often exists on the wire beyond the wireless access device. Devices connected to this wire also implement IEEE 802 technologies, and as such operate on the expectation that each device is associated to a MAC address that persists for the duration of continuous exchanges. For example, switches and bridges associate MAC addresses to individual ports (so as to know which port to send a frame intended for a particular MAC address). Similarly, authentication, authorization and accounting (AAA) services can validate the identity of a device and use the device MAC address as a first pointer to the device identity (before operating further verification). Similarly, some networking devices offer Layer-2 filtering policies that may Henry & Lee Expires 25 December 2024 [Page 6] Internet-Draft RCM Use Cases June 2024 rely on the connected MAC addresses. 802.1X-enabled devices may also selectively block the data portion of a port until a connecting device is authenticated. These services then use the MAC address as a first pointer to the device identity to allow or block data traffic. This list is not exhaustive. Multiple services are defined for 802.3 networks, and multiple services defined by the IEEE 802.1 working group are also applicable to 802.3 networks. Wireless access points may also connect to other mediums than 802.3, which also implements mechanism under the umbrella of the general 802 Standard, and therefore expect the unique and persistent association of a MAC address to a device. Network devices operating at upper layers: some network devices provide functions and services above the MAC layer. Some of them also operate a MAC layer function: for example, routers provide IP forwarding services, but rely on the device MAC address to create the appropriate frame structure. Other devices and services operate at upper layers, but also rely upon the 802 principle of unique MAC-to- device mapping. For example, DHCP services with IPv4 commonly provide a single IP address per MAC address (they do not assign more than one IP address per MAC address, and assign a new IP address to each new requesting MAC address). ARP and reverse-ARP services commonly expect that, once an IP-to-MAC mapping has been established, this mapping is valid and unlikely to change for the cache lifetime. DHCP services with IPv6 commonly do not assign the same IP address to two different requesting MAC addresses. Hybrid services, such as EoIP, also assume stability of the device-to-MAC-and-IP mapping for the duration of a given session. 3.2. Human-related Entities Networks do no operate without humans actively involved at one or more points of the network lifecycle. Humans may actively participate to the network structure and operations, or be observers. Over the air (OTA) observers: as the transmitting or receiving MAC address is usually not encrypted in wireless 802-technologies exchanges, and as any protocol-compatible device in range of the signal can read the frame header, OTA observers are able to read individual transmissions MAC addresses. Some wireless technologies also support techniques to establish distances or positions, allowing the observer, in some cases, to uniquely associate the MAC address to a physical device and it associated location. It can happen that an OTA observer has a legitimate reason to monitor a particular device, for example for IT support operations. However, it is difficult to control if another actor also monitors the same station with the goal of obtaining PII or PCI. Henry & Lee Expires 25 December 2024 [Page 7] Internet-Draft RCM Use Cases June 2024 Wireless access network operators: some wireless access networks are only provided devices matching specific requirements, such as device type (e.g., IoT-only networks, factory operational networks). Therefore, operators can attempt to identify the devices (or the users) connecting to the networks under their care. They can use the MAC address to represent an identified device. Network access providers: wireless access networks are often considered beyond the first 2 layers of the OSI model. For example, several regulatory or legislative bodies can group all OSI layers into their functional effect of allowing network communication between machines. In this context, entities operating access networks can see their liability associated to the activity of devices communicating through the networks that these entities operate. In other contexts, operators assign network resources based on contractual conditions (e.g., fee, bandwidth fair share). In these scenarios, these operators may attempt to identify the devices and the users of their networks. They can use the MAC address to represent an identified device. Over the wire internal (OTWi) observers: because the device wireless MAC address continues to be present over the wire if the infrastructure connection device (e.g., access point) functions as a Layer 2 bridge, observers may be positioned over the wire and read transmission MAC addresses. Such capability supposes that the observer has access to the wired segment of the broadcast domain where the frames are exchanged. In most networks, such capability requires physical access to an infrastructure wired device in the broadcast domain (e.g., switch closet), and is therefore not accessible to all. Over the wired external (OTWe) observers: beyond the broadcast domain, frames headers are removed by a routing device, and a new Layer 2 header is added before the frame is transmitted to the next segment. The personal device MAC address is not visible anymore, unless a mechanism copies the MAC address into a field that can be read while the packet travels onto the next segment (e.g., pre- [RFC4941] and pre- [RFC7217] IPv6 addresses built from the MAC address). Therefore, unless this last condition exists, OTWe observers are not able to see the device MAC address. Henry & Lee Expires 25 December 2024 [Page 8] Internet-Draft RCM Use Cases June 2024 4. Trust Degrees The surface of PII exposures that can drive MAC address randomization depends on (1) the environment where the device operates, (2) the presence and nature of other devices in the environment, and (3) the type of network the device is communicating through. Therefore, a device can express an identifier (such as a MAC address) that can persist over time if trust with the environment is established, or that can be temporal if an identifier is required for a service in an environment where trust has not been established. Trust is not a binary currency. Thus it is useful to distinguish what trust a personal device may establish with the different entities at play in a network domain where a MAC address may be visible: 1. Full trust: there are environments where a personal device establishes a trust relationship and can share a persistent device identity with the access network devices (e.g., access point and WLAN Controller), the services beyond the access point in the L2 broadcast domain (e.g., DHCP, AAA), without fear that observers or network actors may access PII that would not be shared willingly. The personal device (or its user) also has confidence that its identity is not shared beyond the L2 broadcast domain boundary. 2. Selective trust: in other environments, a device may not be willing to share a persistent identity with some elements of the Layer 2 broadcast domain, but may be willing to share a persistent identity with other elements. That persistent identity may or may not be the same for different services. 3. Zero trust: in other environments, a device may not be willing to share any persistent identity with any local entity reachable through the AP, and may express a temporal identity to each of them. That temporal identity may or not be the same for different services. 5. Environments The trust relationship depends on the relationship between the user of a personal device and the operator of a network service that the personal device may use. Thus, it is useful to observe the typical trust structure of common environments: A. Residential settings under the control of the user: this is typical of a home network with Wi-Fi in the LAN and Internet connection. In this environment, traffic over the Internet does not expose the MAC adddress of internal devices if it is not copied to another field before routing happens. The wire segment Henry & Lee Expires 25 December 2024 [Page 9] Internet-Draft RCM Use Cases June 2024 within the broadcast domain is under the control of the user, and is therefore usually not at risk of hosting an eavesdropper. Full trust is typically established at this level among users and with the network elements. The device trusts the access point and all L2 domain entities beyond the access point. However, unless the user has full access control over the physical space where the Wi-Fi transmissions can be detected, there is no guarantee that an eavesdropper would not be observing the communications. As such, it is common to assume that, even in this environment, full trust cannot be achieved. B. Managed residential settings: examples of this type of environment include shared living facilities and other collective environments where an operator manages the network for the residents. The OTA exposure is similar to that of a home. A number of devices larger than in a standard home may be present, and the operator may be requested to provide IT support to the residents. Therefore, the operator may need to identify a device activity in real time, but may also need to analyze logs so as to understand a past reported issue. For both activities, a device identification associated to the session is needed. Full trust is often established in this environment, at the scale of a series of a few sessions, not because it is assumed that no eavesdropper would observe the network activity, but because it is a common condition for the managed operations. C. Public guest networks: public hotspots, such as in shopping malls, hotels, stores, trains stations and airports are typical of this environment. The guest network operator may be legally mandated to identify devices or users or may have the option to leave all devices and users untracked. In this environment, trust is commonly not established with any element of the L2 broadcast domain (Zero trust model by default). D. Enterprises (with BYOD): users may be provided with corporate devices or may bring their own devices. The devices are not directly under the control of a corporate IT team. Trust may be established as the device joins the network. Some enterprise models will mandate full trust, others, considering the BYOD nature of the device, will allow selective trust. E. Managed enterprises: in this environment, users are typically provided with corporate devices, and all connected devices are managed, for example through a Mobile Device Management (MDM) profile installed on the device. Full trust is created as the MDM profile is installed. Henry & Lee Expires 25 December 2024 [Page 10] Internet-Draft RCM Use Cases June 2024 6. Network Services Different network environments provide different levels of network services, from simple to complex. At its simplest level, a network can provide to a wireless connecting device basic address allocation service (DHCP) and an ability to connect to the Internet (e.g., DNS service or relay, and routing in and out through a local gateway). The network can also offer more advanced services, such as file storage, printing or local web service. Larger and more complex networks can also incorporate a multiplicity of more advanced services, from authentication (AAA), to quality of experience (QoE) monitoring and management. These services are often accompanied with network performance management services. Different levels of services may call for different relationships with the device, or its user, identity. For example, there is usually no need to identify the device or its user for a public network to provide a DHCP-sourced IP address to a connecting station, or accept a station using its self-generated IP address (e.g., using SLAAC [RFC4862] ). However, there may be a need, in an enterprise private network, to identify devices in order to provide adapted quality of services (e.g., to prioritize identified voice traffic coming from a smartphone over keepalive data coming from an IoT endpoint). The same type of network may have a need to limit the effect of IP address spoofing and invalid reuse through mechanisms like SAVI [RFC6620] . 6.1. Device Identification and Associated Problems Many network functional devices offering a service to a personal device use the device MAC address to maintain service continuity. Wireless access points and controllers use the MAC address to validate the device connection context, including protocol capabilities, confirmation that authentication was completed, QoS or security profiles, encryption key material. Some advanced access points and controllers also include upper layer functions which purpose is covered below. A device changing its MAC address, without another recorded device identity, would cause the access point and the controller to lose these parameters. As such, the Layer 2 infrastructure does not know that the device (with its new MAC address) is authorized to communicate through the network. The encryption keying material is not identified anymore (causing the access point to fail decrypting the device traffic, and fail selecting the right key to send encrypted traffic to the device). In short, the entire context needs to be rebuilt, and a new session restarted. The time consumed by this procedure breaks any flow that needs continuity or short delay between packets on the device (e.g., real-time audio, video, AR/VR, etc.) The 802.11i Standard recognizes that a device may leave the network and come back after a short time Henry & Lee Expires 25 December 2024 [Page 11] Internet-Draft RCM Use Cases June 2024 window. As such, the standard suggests that the infrastructure should keep the context for a device for a while after the device was last seen. MAC address rotation in this context can cause resource exhaustion on the wireless infrastructure and the flush of contexts, including for devices that are simply in temporal sleep mode. Other devices in the Layer 2 broadcast domain also use the MAC address to know whether and where to forward frames. MAC rotation can cause these devices to exhaust their resources, holding in memory traffic for a device which port location can no longer be found. As these infrastructure devices also implement a cache (to remember the port position of each known device), too frequent MAC rotation can cause resources exhaustion and the flush of older MAC addresses, including for devices that did not rotate their MAC. For the RCM device, these effects translate into session discontinuity and return traffic losses. In wireless contexts, 802.1X authenticators rely on the device and user identity validation provided by a AAA server to open their port to data transmission. The MAC address is used to verify that the device is in the authorized list, and the associated key used to decrypt the device traffic. A change in MAC address causes the port to be closed to the device data traffic until the AAA server confirms the validity of the new MAC address. Therefore, MAC rotation can interrupt the device traffic, and cause a strain on the AAA server. DHCP servers, without a unique identification of the device, lose track of which IP address is validly assigned. Unless the RCM device releases the IP address before the rotation occurs, DHCP servers are at risk of scope exhaustion, causing new devices (and RCM devices) to fail to obtain a new IP address. Even if the RCM device releases the IP address before the rotation occurs, the DHCP server typically holds the released IP address for a certain duration, in case the leaving MAC would return. As the DHCP server cannot know if the release is due to a temporal disconnection or a MAC rotation, the risk of scope address exhaustion exists even in cases where the IP address is released. Network devices using self-assigned IPv6 addresses (e.g., with SLAAC defined in [RFC6620] ) use mechanisms like DAD to and ND to establish the association between a target IP address and a MAC address, and may cache this association in memory. Changing the MAC address, even through a disconnection-reconnection phase, without changing the IP address, may disrupt the stability of these mappings, if the change occurs within the caching period. Henry & Lee Expires 25 December 2024 [Page 12] Internet-Draft RCM Use Cases June 2024 Routers keep track of which MAC address is on which interface. MAC rotation can cause MAC address cache exhaustion, but also the need for frequent ARP and inverse ARP exchanges. In residential settings (environments type A in section Section 5), policies can be in place to control the traffic of some devices (e.g., parental control or block-list filters). These policies are often based on the device MAC address. Rotation of the MAC address removes the possibility for such control. In residential settings (environments type A) and in enterprises (environments types D and E), device recognition and ranging may be used for IoT-related functionalities (door unlock, preferred light and temperature configuration, etc.) These functions often rely on the detection of the device wireless MAC address. MAC address rotation breaks the services based on such model. In managed residential settings (environments types B) and in enterprises (environments types D and E), the network operator is often requested to provide IT support. With MAC address rotation, real time support is only possible if the user is able to provide the current MAC address. Service improvement support is not possible if the MAC address that the device had at the (past) time of the reported issue is not known at the time the issue is reported. In industrial environments, policies are associated to each group of objects, including IoT. MAC address rotation may prevent an IoT device from being identified properly, thus leading to network quarantine and disruption of operations. 6.2. Use Cases Section 6.1 discusses different environments, different settings, and the expectations of users and network operators. Table 1 summarizes the expected degree of trust, network admin responsibility, complexity of supported network services and network support expectation from the user for the different use cases. Henry & Lee Expires 25 December 2024 [Page 13] Internet-Draft RCM Use Cases June 2024 +=============+==============+=========+==========+=================+ | Use Cases | Trust | Network | Network | Network Support | | | Degree | Admin | Services | Expectation | +=============+==============+=========+==========+=================+ | Home | Medium | User | Medium | Low | +-------------+--------------+---------+----------+-----------------+ | Managed | Medium | IT | Medium | Medium | | Residential | | | | | +-------------+--------------+---------+----------+-----------------+ | Campus | Medium | IT | Complex | Medium | | (BYOD) | | | | | +-------------+--------------+---------+----------+-----------------+ | Enterprise | High | IT | Complex | High | | (MDM) | | | | | +-------------+--------------+---------+----------+-----------------+ | Hospitality | Low | IT | Simple | Medium | +-------------+--------------+---------+----------+-----------------+ | Public WiFi | Low | ISP | Simple | Low | +-------------+--------------+---------+----------+-----------------+ Table 1: Use Cases For example: a Home network is sometimes considered to be trusted and safe, where users are not worried about other users (or the home network admin) seeing their MAC address. Users expect a simple procedure to connect to their home network. All devices in the home network often trust each other. The Home network can also include many IoT devices, which need to be simple to onboard and manage. The home user commonly expects the network operator to protect the home network from external threats (i.e., attacks from the Internet). The home user also commonly expects simple policy features (e.g., Parental Control). Most home users do not expect to need networking skills to manage their home network. Such environments may lead to full-trust conditions. However, if the trust commonly exists between allowed actors, there is no guarantee that an eavesdropper would not be observing the Wi-Fi traffic from outside, thus practically limiting the applicability of the trust in most home scenarios. On the other end of the spectrum, Public Wi-Fi is often considered to be completely untrusted, where a user has no expectation of being able to trust other users or any actor inside or outside of the Layer 2 domain. Privacy is the number one concern for the user. Most users connecting to Public Wi-Fi only require simple Internet connectivity service, and expect only limited to no technical support. Henry & Lee Expires 25 December 2024 [Page 14] Internet-Draft RCM Use Cases June 2024 There are existing technical solutions that address some of the requirements from several of the use cases listed above. Appendix A provides a list of some of these existing solutions. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations Privacy considerations are discussed throughout this document. 9. Informative References [draft-tomas-openroaming] Tomas, B., "WBA OpenRoaming Wireless Federation", IETF , 2024. [IEEE_802] IEEE 802, "IEEE Std 802 - IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802 , 2014. [IEEE_802.11] IEEE 802.11 WG - 802 LAN/MAN Standards Committee, "IEEE 802.11-2020 - Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11 , 2020. [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. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008, . Henry & Lee Expires 25 December 2024 [Page 15] Internet-Draft RCM Use Cases June 2024 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Existing solutions A.1. 802.1X with WPA2 / WPA3 At the time of association to a Wi-Fi access point, 802.1X authentication coupled with WPA2 or WPA3 encryption schemes allows for the mutual identification of the client device or of the user of the device and an authentication authority. The authentication exchange is protected from eavesdropping. In this scenario, the user or the device identity can be obfuscated from external observers. However, the authentication authority is in most cases under the control of the same entity as the network access provider, thus making the user or device identity visible to the network owner. Henry & Lee Expires 25 December 2024 [Page 16] Internet-Draft RCM Use Cases June 2024 This scheme is therefore well-adapted to enterprise environments, where a level of trust is established between the user and the enterprise network operator. In this scheme, rotation of MAC address can occur through brief disconnections and reconnections (under the rules of 802.11-2020). Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the enterprise infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address to external observers. The adoption of this scheme is however limited outside of the enterprise environment by the requirement to install an authentication profile on the end device, that would be recognized and accepted by a local authentication authority and its authentication server. Such server is uncommon in a home environment, and the procedure to install a profile cumbersome for most untrained users. Remembering that 2022 estimations count approximatively 500 million Wi-Fi hotspots on the planet, the likelihood that a user or device profile would match a profile recognized by a public Wi-Fi authentication authority is also fairly limited, thus restricting the adoption of this scheme for public Wi-Fi as well. Similar limitations are found in hospitality environments. A.2. OpenRoaming In order to alleviate some of the limitations listed above, the Wireless Broadband Alliance (WBA) OpenRoaming Standard introduces an intermediate trusted relay between local venues and sources of identity [draft-tomas-openroaming]. The federation structure also extends the type of authorities that can be used as identity sources (compared to traditional enterprise-based 802.1X scheme for Wi-Fi), and also facilitates the establishment of trust between a local venue and an identity provider. Such procedure drammatically increases the likelihood that one or more identity profiles for the user or the device will be recognized by a local venue. At the same time, authentication does not occur to the local venue, thus offering the possibility for the user or the device to keep their identity obfuscated from the local network operator, unless that operator specifically expresses the requirement to disclose such identity (in which case the user has the option to accept or decline the connection and associated identity exposure). The OpenRoaming scheme therefore seems well-adapted to public Wi-Fi and hospitality environments, allowing for the obfuscation of the identity from unauthorized entities, while also permitting mutual authentication between the device or the user and a trusted identity provider. Just like with standard 802.1X scheme for Wi-Fi, authentication allows the establishment of WPA2 or WPA3 keys that can then be used to encrypt the communication between the device and the access point, thus obfuscating the traffic from observers. Henry & Lee Expires 25 December 2024 [Page 17] Internet-Draft RCM Use Cases June 2024 Just like in the enterprise case, rotation of MAC address can occur through brief disconnections and reconnections (under the rules of 802.11-2020). Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the venue and identity provider infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address to external observers. Limitations of this scheme include the requirement to first install one or more profiles on the client device. This scheme also requires the local venue network to support RADSEC and the relay function, which may not be common in small hotspot networks and in home environments. It is worth noting that, as part of collaborations between IETF MADINAS and WBA around OpenRoaming, some RADIUS privacy enhancements have been proposed in the IETF RADEXT group. For instance, [draft- ietf-radext-deprecating-radius] describes good practices in the use of Chargeable-User-Identity (CUI) between different visited networks, making it better suited for Public Wi-Fi and Hospitality use cases. A.3. Proprietary RCM schemes Most client device operating system vendors offer RCM schemes, enabled by default (or easy to enable) on client devices. With these schemes, the device changes its MAC address, when not associated, after having used a given MAC address for a semi-random duration window. These schemes also allow for the device to manifest a different MAC address in different SSIDs. Such randomization scheme enables the device to limit the duration of exposure of a single MAC address to observers. In 802.11-2020, MAC address rotation is not allowed during a given association session, and thus rotation of MAC address can only occur through disconnection and reconnection. Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the venue and identity provider infrastructure, directly proportional to the frequency of the rotation. The scheme is also not intended to protect from the exposure of other identifiers to the venue network (e.g., DHCP option 012 [host name] visible to the network between the AP and the DHCP server). Authors' Addresses Jerome Henry Cisco Systems United States of America Email: jerhenry@cisco.com Henry & Lee Expires 25 December 2024 [Page 18] Internet-Draft RCM Use Cases June 2024 Yiu L. Lee Comcast 1800 Arch Street Philadelphia, PA 19103 United States of America Email: yiu_lee@comcast.com Henry & Lee Expires 25 December 2024 [Page 19]